Software Development as Metaphor

As I mentioned earlier, I'm working on a giant project for a client of mine. I've worked on several other projects for this client, and each one has gone very, very badly. Not in the sense that the people are bad or that working with them is difficult, but that the end product is simply bad: doesn't live up to its potential, doesn't work as well as it should, is, in essence, unusable.

And the question is why. Talented, experienced people are involved. Proven methodologies are used. A strict development process is instituted and followed.

In my opinion, the problem is that their development process treats people as cogs in a wheel instead of as creative individuals.

Here's how these projects run:

  1. Some VP writes a high level definition. The VP has some people write requirements for it and IT provides a cost estimate.
  2. The VP shops the cost estimate up the political chain, and receives approval to spend $x.
  3. The VP puts a small team on it: representatives from business, IT, project manager and hopefully user interaction.
  4. Before the small team feels like it has a well-rounded solution, Use Case teams are brought in to document everything.
  5. Before Use Case teams are done, scores of developers are put on the project in an attempt to hit the deadline.
  6. Once there's something to test, UAT (User Acceptance Testing) is conducted, which is an attempt to test that every single item in the requirements document has been completed.
  7. The project is launched, and training commences.

Aside from the obvious (why don't you wait until each phase is done?), makes sense, right? Well ... no. The above is an example of the standard Western, Market Economy driven mindset: get 'er done by bringing in hordes of "experts" when the "proven methodology" states they should. But that's exactly the problem. It's an over-reliance on a methodology instead of counting on humans to build something for other humans.

Here's a different way:

  1. The VP writes a definition, and is now tasked with shepherding the entire project to completion.
  2. The VP builds a small core team consisting of a high-level business-side person, a high-level IT person, a high-level project manager and a high-level user interaction designer. This team works with the VP to flesh out the definition to the point they feel comfortable estimating cost.
  3. Once the VP gets funding for the project, this same team works the project through, ending up with an actual prototype.
  4. The prototype is usability tested and shopped around the company for acceptance. It becomes the proof that the spirit of the VP's vision has been attained.
  5. Assuming everything checks out, that same team brings on a few more people to develop the final product. Database and middleware architects plus documentation. The goal is to keep the entire team no larger than 10.
  6. Build, adjust to new discoveries, test it with real customers, make sure the VP is intimately involved in any discovery that affects the initial vision.
  7. Launch it.

The difference? The second method treats all disciplines of any major IT project as intrinsically valuable by bringing them together at the very beginning. The first method treats none of the disciplines as valuable at all -- everyone serves the process when the process needs bodies.

And to me, that's why the first method is a metaphor for everything that's wrong with Western Capitalism. Bigger, faster, better ... our assumption is that to continue to grow and to therefore be more attractive to Wall Street, we must be more efficient, and the only way to be more efficient is to automate, and the only way to automate is to build a process that runs by itself.

What we've done is to bring The Terminator's metaphor into being. We are being taken over by machines, and they are us.

0 comments: