Tuesday, August 28, 2007

You Gotta Stand Up For What You Believe In

Built To Last and Good To Great left me with a lot of ideas to digest, but I'd like to touch on two of them. In Good To Great, part of the Hedgehog Concept involves the journey in finding the "core" that you believe in. In Built To Last, half of the foundation for building a visionary company is "Preserving the Core."

How do you find the core? It has to be something you're passionate about. Philip Morris is passionate about offering products and defending your choice to use those products. You may not agree with that stance, and if that's the case, working at Philip Morris is probably not a good idea. Nordstrom's is passionate about customer service - almost fanatically so. If you aren't, you won't fit in.

These companies spent a while looking for their core values. Once they found them - they were passionate about keeping them, and developing a company where the values would flourish, by hiring (and keeping) individuals who shared those values.

This is of the utmost importance. At the point where you're looking for employment in your life, your core set of values is probably established. It becomes harder to change these as you grow older. Don't be afraid of what you truly believe in. If you're passionate about something, find and surround yourself with others who share these values. By the same token, a company should actively seek to hire individuals that identify with it's core values.

For software companies - I think there is a key difference between core values and core competencies. I feel far too many recruiters and jobs focus on technical skills that can be acquired by any good developer in a few weeks. Focus on the values the developer holds. Are they disciplined? Are they enthusiastic? These are more important, as these traits will drive them to always be learning the technical skills they need to help them succeed (and your business, as well).

Disclaimer: There is still a core level of technical competency that any developer needs. I think it's hard to really quantify it, but anyone working as a developer definitely needs technical skills. They are, after all, what allows us to do our jobs. I just don't feel that measuring someone solely by their laundry list of buzzwords on their resume is a good indicator of their true worth.

Monday, August 20, 2007

DJ Z-Trip at the Granada

My wife and I went to see DJ Z-Trip at the Granada last night. It was one of the best shows I've ever been to.

Any time you can hear Led Zeppelin mixed with Jay-Z is definitely a good time.

Watching Z-Trip mix is a sight to behold. I've never seen anyone so into what they were doing. He looked absolutely thrilled to be doing what he was doing - the enthusiasm was infectious.

Aceyalone and Gift of Gab were fantastic, as well. I definitely need to check out Blackalicious.

The opener DJ, Tricky-T was pretty good as well. Not as good as Z-Trip, but definitely talented.

The drummer was great too. They gave him a good 10 minute set, with nothing but the drums.

My wife and I got a chance to meet Z-Trip, as well. Real nice guy, gave my wife a big hug like he'd known her for years. She had bought a shirt and he tagged the back of it.

If you have a chance to catch any of the remaining tour dates, I'd definitely recommend doing that.

Thursday, August 16, 2007

FindControl and UniqueID

The FindControl method is not recursive. Should have done that Google query before I spent 3 hours debugging.

Imagine you've gotten a page that adds user controls very late in the page lifecycle - after Init, in any case. Like any good control developer, you're definitely going to recreate the control tree after postback, but you have some additional requirements. In addition to adding the control to the tree, you need to keep track of certain types of controls, and re-apply some properties to them. Like, a "collapsed" property, for instance.

So, you throw some control ID's into a StateBag (I really like that class name) to retrieve later, to apply the properties to each control. You have the ID, and you have the control type - should be easy to find the controls on each page, and then apply properties, right?

Wrong. Not if you don't know where in the tree it is. Page.FindControl(controlID) doesn't work if it's deep in the tree. However, using our handy-dandy Reflector, we can see that FindControl uses ID and UniqueID, which:

Gets the unique, hierarchically qualified identifier for the server control.

Ahhh...just what I need. The ID and where it is in the tree - all without having to to implement FindControlRecursive (for now).

Friday, August 10, 2007

Software Companies and Discipline

Anderson brings up to my next point - what would you consider discipline in a software company?

The first discipline concept is Disciplined People. Most top-notch software shops know how to hire disciplined employees - individuals who never stop learning, and who are committed to building (and shipping) great software. You want everyone on board to be serious about their craft (whether it is a developer, tester, or manager). They need to have both the guts and the ability to take your company to Great (as capitalized by Jim Collins).

The next concept is Disciplined Thought. You've hired the right people. They have the raw abilities, and they have the gumption to perform at their best. Now, comes the unified part. You have to harness all of that discipline and focus it on your software. This is hard. You need to create a sense of unity. It's not the testers vs. the developers. It's not management vs. everyone else. The entire team needs to be "signed up" to deliver Great software. Again - if you've got Disciplined People, this part should be cake.

Finally, there's Disciplined Action. This is definitely the hardest part to "get right." It's crucial that the first two ideas happen before this one can be truly successful. I myself have a hard time with it - undisciplined thoughts that turn into actions can make it look like it's a failure in execution, rather than planning. (Especially when you have several successes under your belt.)

Developers are notorious for being bleeding-edge adopters. It's practically a badge of honor to be running nothing but beta software on one's machine. I'm no exception - it's happened in the past, and right now I've got two different versions of Visual Studio running side-by-side. What happens is if you let this tendency run wild in your software, you will have problems. I'm not saying new technology is a bad thing. I can't wait to replace some of my Dictionaries with HashSets. LINQ is undoubtedly cool. And don't get me started on lamdas. But, there's no way I would try to integrate .NET 3.5 into an existing project that needs to ship anytime soon. I've been down that road before, and I know where it ends. (Hint: it's a particularly "deathly" kind of "march.")

You get the right people, who will make the right decisions, and execute them properly. For a software company, this means hiring people who will ship great software, and base their decisions and actions around that concept. Developers write high quality, unit tested code. Testers make sure the code meets requirements and is of high quality. Managers keep the machine running smoothly, and block any attempts to foul it up. Business analysts figure out what the customer really wants. And no one makes decisions that will run contrary to the desired outcome - shipping Great software.

Thursday, August 09, 2007

Discipline and Unity

I've just about finished up Jim Collins' Good To Great audio book, and I've recently finished Dynamics of Software Development by Jim McCarthy. After reading/listening to both, I've come to the conclusion that:

  1. For a software team to become successful, you need a common understanding of the goal. Every member needs to know what the final desired outcome is.
  2. Every team member also needs discipline. Jason Alexander sums it up better than I could.
With discipline and a clear goal, everyone focuses on the outcome with all the effort they can muster.

Now, there are obviously more factors that contribute to a successful team, but I feel like these are some of the most important ones. If your team has these qualities, you're definitely on the right track.

Thursday, July 12, 2007

Raising the Lowered Bar – ASP.NET and the Barrier of Entry

Developers, developers, developers! It's been Microsoft's mantra for a long time. They had the VB developers "back in the day" (a Tuesday, I believe) and when .NET came out, they needed a way to keep them.


So, what do you do with a bunch of developers that don't want to learn a new way of doing things? Simple - don't make them learn.


ASP.NET has a low barrier of entry


So, now, there's this new .NET "thing" and there's all sorts of ways to make a presentation layer for your applications. You can start using WinForms, or you can use ASP.NET. (Now, you can also start using WPF, or Silverlight, but we're talking about the dark ages of 2002. Bear with me.) From what I recall, it seems like that Microsoft was pushing ASP.NET pretty hard, and leaving WinForms as a not-quite second class citizen.


So, ASP.NET. It's fantastic. I loved it and I still think it's a fantastic platform for any development - web-focused or otherwise. Microsoft did too, and they did several things to make it easy to start developing applications in ASP.NET. They used a lot of conventions from the old VB world of Forms development (TextBox, Label, Button) for the presentation, and they presented a fairly robust event-driven model for UI interaction. They kept the same basic state management tools available to you from ASP classic, and tried to make it as easy as possible to migrate existing ASP applications to .NET.


(Side note - anyone who's actually done a migration like that with a "real" application knows that it's not trivial at all. But Microsoft did try.)


What Microsoft failed to do with ASP, and what they sort-of did with ASP.NET was abstract the messy land of web development, with it's:



  • HTTP verbs (POST, GET)

  • Javascript

  • the HTML DOM

  • CSS

  • Different browser issues (usually related to the items above).

They shipped a bunch of tools (DataGrids, several wizards) that would allow you to make your easy, cookie-cutter "enter some data and display it back to the user, or throw it in the database" applications very quickly.


I know I'm glossing over a lot of stuff. Bear with me.


Rails and Scaffolding


What? Ruby? Rails? Blasphemy!


Seriously though, this is great stuff. I have yet to do more than play with it, but I've made a commitment to start learning something new, and Ruby is a start.


So, what do I do? I start reading blogs. I've been reading a lot of Giles Bowkett. He's abrasive, but he takes a side, and I like that. Something he touched on is part of the inspiration behind this whole article:



I recently tried to get the Rails core team to switch the for loops in the scaffolding templates to iterators, on the grounds that this would encourage new Rails programmers to use iterators instead of repeating their bad old habits with for loops. I failed completely. Josh Susser said that replacing for loops with iterators would set up a barrier to adoption for new Rails programmers, and that was that. The idea didn't fly for a second.


So - barriers of entry <=> Bad.


The whole philosophy behind the Rails team is to get programmers using Rails (and Ruby). The easier it is to switch, the better.


The state of Web Development Now


So, what's happening now? You don't find a lot of WinForms developers, for one. I've been on job hunts recently, and let me tell you - Microsoft shops don't care about WinForms. They all want ASP.NET. (Or they're stuck supporting their old VB apps. But they're moving them to ASP.NET.)


So, now all of the developers working on Microsoft's platform have ASP.NET based applications. You have zillions of web applications out there that basically all do the same thing - enter data into a database and display it back later. And a lot of them are exactly the same. Sure, the database is different, and the colors are different, but there's not a huge differentiator in applications that are developed for ASP.NET, if you stick to the DataGrid/GridView application model.


Where you find the truly outstanding applications now, is both a great idea, with great execution, in ways that make that web browser dance. And there's frameworks out there that try to help you (ASP.NET AJAX, control suites like telerik or ComponentOne).



However, several of these still provide somewhat leaky abstractions. FileUpload controls don't work correctly in UpdatePanels. Validators don't work correctly anymore. ComponentOne's grid looks great, but only if you're willing to put up with it's bloat. (It emits a TON of code to the browser.)



However, think of those applications that just give you the "holy shit" moment when you figure out what's really going on.




I'm sure you've probably got your own list, but these are ones that really stuck out in my mind. And what do they have in common? These applications were built with the understanding that the browser is fickle, but powerful, and take advantage of the HTML/CSS/Javascript "mess."



Go Learn Something!



So, what's the point of all this? Go learn what you're emitting to the browser! Here's some problems that, without knowing about the HTML DOM and Javascript, I would have had a nightmare of a time dealing with.




  • The ASP.NET Label - is there any more mis-used control? This needs to have the AssociatedControlID property filled in, so that it actually renders as a <label> or you'll end up with a <span>. Heaps of problems there. Much better to use a Literal if you're just trying to throw some text up on the page.

    Side note - DataBinding (for globalization), in my experience, is easier with a Label. It has all the properties that you'll need to globalize. So, what can you do? Override the default rendering (as a <span>) with something else if it's screwing up your CSS. Or roll your own control. The CSS Friendly Adapters are a good place to start.


  • The DataGrid, or the GridView. Good for simple stuff, but I bet you won't find many of those on anything that is public facing - too much to send up to the browser. Use a Repeater instead.


    Scott Watermasysk has a great article about these tips, and others as well.




I'm sure there are other problems out there, but these are just some of what I've encountered. But, without the big picture, I couldn't have solved them as effectively as I would have liked.



Congratulations! You've reached the end. Thanks for reading, and I'll (hopefully) have some more in the future.

Saturday, June 30, 2007

Please sir, may I have another?

Between my wife and I, we own a PlayStation 2, Gamecube, Xbox, Dreamcast, Super Nintendo, and a Nintendo 64 and NES in storage.

We've also gotten into board games recently, and we own Settlers of Catan, Ticket to Ride, Louis XIV, and Risk Godstorm and Risk Star Wars (Original Trilogy, of course. Thanks Zach!). We like games.

We also have had a launch Xbox 360. It finally decided to flash the dreaded Red Ring of Death 2 weeks ago, so I called to get it replaced.

I recieved the "new" one yesterday, and was very excited to try out Carcassonne (our first Euro-board game experience, shared with The Imes).

Instead, I'm treated to the console freezing. Constantly. Any notification will freeze the system within a second or two, forever letting me know that PoofyLake or BooleanFlag is now online. Playing a video is certain to cause the system to freeze before about 30 seconds have elapsed. And forget games. Oblivion locks up, GoW locks up, even Arcade titles.

So, I'm getting a "new" one again. I really hope they get it right this time, and I don't end up like this guy.

We'll see.

Monday, June 18, 2007

TouchPoint Released!

Something that I got to watch be developed by a good friend of mine was released recently.

Go check it out - very cool stuff. Kudos!

(6/20/2007) Edit - changed link.

Thursday, June 14, 2007

I Think That Snicker's Bar has Gone Bad

So, I got low blood sugar and decided to grab a candy bar from the machine. I bit into it and here's what I saw:


Scared the be-jeebus out of me. Turns out it's movie promotion for Shrek.
Seriously, who comes up with this stuff?

Wednesday, June 13, 2007

My Dog Ate My Blood Sugar Meter

The title just about sums it up. Zach has heard all of my "my dog ate..." stories by now, but this one was just too good.

There's a big crack in the LCD cover. The LCD isn't actually cracked, but it's still hard to read anything.

Since I now have insurance, I figured that I'd check the website to see what the copay would be on a new meter. I had to sign up first though.

It asked for a username, with the following verbage:

Please enter your desired username. Must be between 5-50 characters

I enter my standard username, fill everything out, and am then greeted with the following error message:
Your username must contain both letters and numbers.

Oh, really? Would it be that difficult to put that statement above the username entry field? Or, even better, not require numbers in the username? Is that really necessary?

Did they even set a real user down to run through the sign-up process before it went to production?

Tuesday, June 12, 2007

Safari Hates my Proxy Server

So, Safari for Windows. I'm not the first person to talk about this, and they'll have much more interesting things to say, so I'll keep it short.

I'm behind a proxy server that requires domain authentication. FireFox works great. Windows LiveWriter works fine. Windows Media Player (using XM Radio Online and Urge) works just fine. Opera has no problems.

Safari crashes the instant I try to authenticate. Every time.

I know it's beta, but still - not too impressed so far.

Friday, May 18, 2007

Oh, The Places You'll Go

Leaving a job is never easy, especially when you've been a part of moving the company forward.


Recently, I learned that a lot of the frustrations that I had with my previous position were being addressed directly

They are moving forward, implemented Scrum and a lot of the changes I was pushing for, and have turned the development team into a highly motivated, effecient team with a great sense of camraderie.


And that's awesome. I just wish I could be there to see it happen. It's a shame when the changes can only be brought about with a major catalyst, such as someone leaving the company.


Best of luck, team A.D.D. - I know this is going to be great for you all.

Thursday, May 17, 2007

Get XmlDocument from a class

So - I've been trying to find an easy way to add a ToXml() method to a lot of objects lately. Here's what I've come up with:



MemoryStream ms = new MemoryStream();
XmlWriter writer = XmlWriter.Create(ms);
XmlSerializer xs = new XmlSerializer(this.GetType());
xs.Serialize(writer, this);
XmlDocument doc = new XmlDocument();

// Need to start at the beginning of the MemoryStream
ms.Seek(0, SeekOrigin.Begin);

doc.Load(ms);
return doc;


The Seek method took me the longest to figure out. I kept getting a "Root node is missing." exception.


Hope this helps someone.

Friday, May 11, 2007

CodePlex and Subversion

As I've posted about before, Subversion is a great tool. It's

  • Open Source
  • Free
  • Fast
  • Easy

Rob Conery and his awesome SubSonic project are hosted on CodePlex, which uses TFS as it's backend. I'm working with TFS now (at work) and it's a great solution for the teams we have here. But, I don't think it's appropriate for the CodePlex community.

And Rob's losing contributors - something no open source team wants to happen.

So - here's my two cents. CodePlex should switch to Subversion. It's a much more appropriate source control tool (for this type of collaboration) and I'll even go out on a limb here and say that if they do switch, I'll personally see what I can do to start contributing to SubSonic.

Wednesday, May 09, 2007

I Took the Web Design Survey


Found from Eric Meyer.

I Took It!  And So Should You.  The Web Design Survey.

Monday, May 07, 2007

Team Hanselman Fights Diabetes

As I've mentionend before - I'm a Type 1 Diabetic.

And Scott Hanselman is as well. And he's raising money to fight it. Which is awesome.

Team Hanselman - Fight Diabetes

Friday, May 04, 2007

Everything I ever needed to Know about Database Design, I learned from .netTiers

OK - not really. But, it's a good play on words.

I recently evaluated CodeSmith and .netTiers to help me develop the middleware for a project I had been working on. I'd like to talk about some of my experiences, and what I learned.


  1. .netTiers doesn't like tbl_.

    Originally, the database had been developed with the tbl_table_name convention - and although there's a StripTablePrefixes in .netTiers, it seemed like it was being ignored. I remedied this problem by scripting up the entire database, applying Regular Expression Magic™ to change the table names to PascalCase, and then re-created.

  2. Don't name any of your tables anything that might be a type in .netTiers framework - like Entity, for example. Originally, we had thought to have a generic "business entity" table that held customers and system users. This turned out to be a bad idea.

  3. Relationships and indexes are awesome. .netTiers will generate any "Get" methods based on any index that return strongly-typed Entities or List collections, depending on if the index is a unique constraint or not. Very cool. Also, you can have GetCollectionFromRelationship() methods that do the same thing.

    Plus - you've made a head start on optimizing your database.

  4. If your schema has problems, and .netTiers doesn't compile - better to find out now, rather than later. This was a rather rude awakening for me - I thought I had a grasp on some DB design. I now have a much better one.

Overall - highly recommended. It doesn't come cheap (you need a licensed version of CodeSmith), but if you're already using CodeSmith - definitely give this template a shot.

One other caveat - it's open source, which is great. But, the documentation is a work in progress.

Dynamic Ducks! Dynamically! (Functionally too!)

So - with all this talk about the DLR and dynamic languages becoming first class citizens in the .NET Framework, I'm going to make a commitment. Here. Where about 10 people read.

I'm going to really learn a functional, dynamic programming language. I'm going to really understand lambda's. I'm going to figure out why those Ruby, Smalltalk, Python, and Haskell guys all start frothing at the mouth. I may even figure out this JavaScript thing.

I did get a B.S. in Mathematics - so I'm not too worried. Being a math guy and hearing about these functional languages intrigues me. Plus, with C# 3.0 coming out soon, I might even be able to apply this skill to my day job.

I don't know what I'm going to do yet, but I'm going to do something.

Thursday, April 26, 2007

Buy me a Pink Cadillac

Today is my last day at Ariamedia. I was recently offered a position developing software for Mary Kay, and I will start on April 30.

It's been a tough decision to leave. I enjoyed working at Ariamedia, and met a lot of awesome, very talented individuals. I'm sure I'll be hearing about all of them in the future. My team has been on a push to get the software development lifecycle more agile (Scrum specifically), and I'm very glad to have been a part of that. I was also a big part of getting our source control moved to Subversion. I'm definitely glad I was involved with that - I'll never go back to SourceUnSafe and now, I don't have to.

Choosing Mary Kay was a big decision for me. I've never worked in a corporate environment. I've never had to wear a tie to work. So, that will be interesting.

I'll be glad to be working with a good friend of mine, as well.

I also had another very enticing offer that, while I didn't accept, I was very flattered to have received, and I'm glad to know that avenue is open to me. However, after looking at the choices that I had, and where I'm at in life, I'm happy with my decision.

Leaving a job is difficult. I've made friends, learned new things, and done a lot of (I hope) good work. You always leave with projects unfinished, but I know that I'm leaving them in very capable hands.

So long, and thanks for all the fish.

Tuesday, April 17, 2007

Automatically insert SortOrder value in SQL

So, the other day I ran into an interesting problem. I've been using CodeSmith and .netTiers to develop all that "boring business/data access code" for an application at work. One of our requirements was to have a list of things with a user-specified sort order.

So, I added a SortOrder column to the table (not sort_order, but more on that later), and ran my code-gen. I didn't want to put the "automatic sort order insertion" into a stored procedure (since they're all generated), but I also didn't want to have to hit the database several times just to figure out what the next value should be.

Then someone showed me that you can have a function for a default value in a column in SQL Server. I knew this instinctively (NEWID() for a uniqueidentifier, or GETDATE() for a "date inserted" column) but I hadn't thought about using my own function.

So, here it is:

DECLARE @newMax int

SELECT @newMax = MAX(SortOrder) + 1 FROM TableWithSortColumn WHERE SomeForeignKeyId = (SELECT SomeForiegnKeyId FROM TableWithSortColumn WHERE Id = (SELECT IDENT_CURRENT('TableWithSortColumn')))

RETURN @newMax

I just created the function, set my default value for the sort column to dbo.GetNewSortOrder() and

Disclaimer: I'm not particularly sure this is really the right place to do this type of thing. If anyone has any suggestions or comments, please let me know. If you think this is a terrible idea and will cause my application to start fires and kidnap small children - definitely let me know. I'd like to avoid any legal entanglements.

Friday, March 02, 2007

i'm Making a Difference

Just ran across this while doing my morning blog checks.

Basically - Microsoft will donate a portion of the advertising revenue they recieve for every Messenger conversation you participate in to charity. All you have to do is add an emoticon to your display name.

I think it's a great idea - especially if you already use Live Messenger.

Tuesday, February 13, 2007

Hello, my name is Nic. And I'm a Diabetic.

Yesterday, I did something I haven't done in quite some time. I went to an endocrinoligist, or what I like to think of as "the hormone doctor".

I'm a Type I Diabetic. Many who read this blog probably already knew that. If you are one of those who's been reading that I don't know personally - please leave a comment. I'd love to know how many people actually read this thing.

I've read a lot of articles and interviews with diabetics, and it seems like so many let the disease become the focus of their lives. I remember reading one where a woman refused to take a 2-week vacation because she couldn't get enough backup supplies to last for a month. In Las Vegas, which is technically in the middle of the desert, but I'm pretty sure they have pharmacies in Vegas.

I feel that having diabetes is part of who I am, but it doesn't define me. Yes, I have to watch what I eat. So should anyone trying to be healthy. I have to take shots before every meal - no big deal. It's over and done with in about 3 minutes. I take Gatorade (or Powerade, or Generic-Sports-Drink-Ade) when I work out in case my blood sugar gets low. Just like most people working out. I wear a medic-alert necklace that would let someone know of my condition, in the case of an emergency.

But that's about it. I don't let it run my life, or ruin my plans. I just have to make adjustments when they come up.

I hadn't gone to the doctor in a while, because I've been without medical insurance for the past 3 years. I finally got insurance and can afford to go to the doctor, and my insulin and supplies aren't going to cost a fortune. It's a good feeling. In fact, paying for my diabetic necessities is now relegated to a financial "annoyance" status, instead of a financial "oh crap I can't afford to fix my car because then I can't buy my insulin" situation. Which is just how I like it.

Wednesday, January 03, 2007

Battlestar Galactica and Developing Software

For Christmas this year, my wife got me some really cool gifts. And a few days ago, I read an article that Joel linked to in his Dreaming in Code article. It got me to thinking, especially Joel's Yiddish to English analogy.

The two books, in particular, were very good. The meat of the books focuses on the creation and inspiration for the episodes, including the starting concepts (the episode Scar was initially just an idea: "the Red Baron episode") and their evolution into what I saw when I plunked my butt down on the couch with my wife and friends every Friday night.

There seemed to be a lot of vague ideas that went from brainstorming sessions, to screenwriters, to the producers, back to the screenwriters, to the producers, back to the screenwriters, to the producers, the director, back to the screenwriters (yes, I am repeating myself on purpose), and so on. And once a script was written, the actors would do take after take until the director was satisfied.

It got me to thinking about how many teams approach software specifications, estimates, and that oh-so-fuzzy factor I like to call "Client Satisfaction." This client can be the general public (if you do shrinkwrap software), the big multinational corporation that's going to send your consulting business into the stratosphere, or your professor grading your midterm project.

You start with an idea: We need an "inventory system." If you're like some custom-software consultants, at this point you send a fleet of analysts that "speak customer" to try to figure out how to translate "inventory system" into a 200-page specifications document.

Then, the document goes to the developers to estimate, of if you don't want to use that word as a verb, to give an estimate. Read that last word again. Estimate. Dictionary.com defines estimate as:

to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately

or

a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work

Notice the key word in both definitions: approximate. We all know what that means (as I'm sure you knew what estimate meant, but I'm trying to illustrate something, so bear with me.)

Approximate. Why is it that an approximation in many software shops is treated like a prediction from Nostradamus, and not more like a "I hope it takes this long, but maybe not." If you're someone in charge of scheduling, please don't divide this by some number (usually 8, which is wrong), figure out which day of the week that falls on, and sign a contract with a client gauranteeing that it'll be done on that day. You'll be sorry.

In the past, I've been tasked with estimating very large pieces of software. There's been some with very well-written specification documents, and most of what has been asked of me is not difficult, at first glance. There's been others where it was just an idea.

Usually, when it comes down to giving the final "magic number" of hours, it's not that that number is balked at. It's that several times, scheduling based solely on that number of hours usually results in missed deadlines, frazzled developers, and perhaps most importantly, unsatisfied customers.

Why unsatisfied customers? In my experience, when I've developed larger applications, with a traditional BDUF pattern, the customer won't see a product until about 75% of development is done. By then, they've probably formed some more concrete ideas in their heads of what they want, and since they're (most likely) not developers, it may not be what you give them.

What does this have to do with TV? Many of the roles are analogous. Actors are developers - their performance can be thought of as the actual computer. Screenwriters function as a business analyst. The director is the client. (You could argue they're QA, and the client is the viewer. But it's my blog, so I'm making the analogies.)

There's lots and lots of revisions in this process. The client gets immediate feedback from the program's output, and if he doesn't like it, he asks the developer to try again, "with feeling."

This is something that many need to realize about developing software. The client has a fuzzy idea about what it is they want, and it's hard to nail that down in "specifications documents" or "business requirements." I'm not advocating throwing these documents out the window - well-written specs are invaluable to have. They need to evolve with feedback from the client - and it needs to be sooner, rather than later. And you better schedule that in too - because no client is ever satisfied with the first draft.

That's why good actors are paid lots of money - they start to instinctively know what it is their client wants and can give it to them with the least amount of iterations. I think that people who serve this role in the development world, like free electrons, or business analysts that are "good at dealing with people, can't you understand that?" are who you want on your team. They can get the satisfaction up high with the fewest iterations. They grok what the customer really wants.

So, remember this: clients don't know exactly what they want. They have an idea. Help them shape and mold that idea until they look at you give them and say "YES! That's what I've been after." Be sure to build that into your schedule too.

It would be nice if we could have a "satisfaction requirements" document, though. That's definitely the answer.