Coding Blind

(archived from my old blog from my pre-MS days)

I remember a cartoon I saw in the early 90's regarding the way that software projects were sometimes run.  The punch line was, "You guys start coding, I'll go find out what they want." 

The industry's answer to that was the onset of "Big Requirements Up Front" - (BRUF).  Waterfall.  RUP.  UML full-trip code generation/regeneration - and like most things, it was something of a pendulum swing - reacting to the cowboy coders with a methodology that prevented writing any code that was not useful.  Get all those requirements up front - they'll never change.  Implied in the "They'll never change" was that any analyst worth their salt would make sure that you're asking the right questions, then requirements never change.  Requirements only change when you've gotten the wrong requirements.

But requirements do change, even if you've done a good job up front.  No one has all the info.  Decision makers don't always have the right info.  Things change.  And in RUP - if you were doing it "right" you had oodles of documents to modify if requirements ever "changed."  Not to mention the fact that you're most likely going to hit your client up for more money - they always love to hear that.  Change requests anyone?

In reaction to that, agile & XP arose.  Power to the Programmers!  But there are those who have taken that pendulum swing back too far as well.  We don't need no stinking Architects!  The problem with this approach is that you ignore resources that are already available here, sometimes called the "Not Invented Here" syndrome.  I confess that I've been guilty of this.  I love to code.  I'd rather be coding than analyzing any day.  It's not fair to the customer, however, to ignore the groundwork that other's have done in order to get my coding fix.  A few months ago a client had a project where they wanted to provision all accounts from a single request "front end."  I automatically thought "new web site," and for a long time ignored the fact that they already had a MOSS site available internally.  These account requests fit fine within the paradigm of a SharePoint list.  I almost went with a custom web site in spite of that, but in the end, I could not justify the fact that I'd spend a lot more on this custom web site than I would with MOSS.  In the end, I did get to do a good bit of coding, since we had to implement a custom MIIS extensible management agent to get into and out of MOSS.  I did end up getting my coding fix.

So the moral of the story is - don't assume that you're going to do it better than anyone else who's already done the same.  If you have the opportunity to exploit the collateral of others, do so where it makes sense.