N-Tier development with C# 4.0

Now that the PDC announcement has been made revealing sessions covering the new C# 3.0 features causing speculation to run rampant, I figured it was time to go ahead and start outlining features of the next product.  No reason to be stay focused on the past.  It's time to move on and discover what lies ahead. 

Too soon, you say?  Are you kidding?  Of course not.  Look, the design staff here has to keep planning far in advance of the development juggernaut.  If we were not constantly leaping ahead into product plans n-versions out, the developers might start to think that the ship was drifting off course and that everyone was asleep at the helm. If that ever happened, the negative impact to employee morale would be devastating, sending productivity into the toilet, initiating a downward spiral of fear, uncertainty and drunken binge programming that we might never recover from. 

Sure, we’ve squeaked by before without a clear progression of product visions, attempting to ship fledgling one-off’s anyway. You’ve seen the aftermath; tons of ill phrased dialogs, oodles of incoherent error messages, menu items haphazardly placed and the invention of the tool-bar. Fortunately, as a company, we eventually came to our senses. To rectify the problem we instituted a process whereby planning for the next version commenced while the current version was still in production.  Put into practice, this seemed to quell the fears emanating from the developers cubbies.  It kept them productive and happy; and the products tended to ship more or less on time.

Yet even with that improvement, the company still had a long way to go to perfect the process.  You see, while the developers were now content to continue churning out bits, bugs and brochures by the bucket-loads, the designers were quick to point out that they too were consumed by a similar dread; no one was looking ahead to the next, next version.  Even as the current next version was successfully congealing in their minds, the lack of a plan for the follow on to the next version caused substantial despair.  Design meetings quickly turned into squabbling.  If a designer’s favorite feature was not on the table for the next release, then it obviously was never to going happen and we all might as well pack up and go home, or at least go into research. The inability to see beyond the next, next horizon was corrupting the very process by which the morale of the development teams hinged.  It did not take a genius to realize that implosion was imminent.

Of course, that’s why we revised the process to include the n-tier development cycle.  It requires that design teams stay n-versions ahead of the actual product, usually by dividing up into multiple tiers of overlapping forward-thinking units. Of course, it would be silly to consider staffing up n-teams of thinkers constantly thinking beyond each other.  Any team left in the nth position would invariably begin to feel the angst of future uncertainty, the creeping anxiety of doom.  So naturally, we would need to devise a structure that would avoid identifying any particular ‘n’.  In the end, we chose to form ourselves into a ring of buddy-teams each dedicated to working one version beyond the buddy team to the left.   

I’m so giddy to be part of this process. I can hardly imagine working under the old regime.  How does the rest of the industry manage to limp along without a clear roadmap ahead?

But I digress

Matt