This week we review managements understanding of an important software engineering concept -- The Prototype.
There are, generally speaking and with no claims of deeper research
than drinking coffee, only two types of software prototypes: the Investigative and the Demo.
The Investigative prototype is there to answers the simple question of 'can we make it work?'.
Also known as the Proof-Of-Concept. You have an idea. You're not sure
if what you want is even feasable with what you have. So you try to
knowck something up to see if you can get there from here.
The Demo prototype is there to answer the age old question of 'will you give me money for this?'.
Also known as the Hard-Coded-Slideware. You think you can make a
product. You need to show it to potential customers, investors or
focus-groups with the ultimate, sometimes implicit, question being 'is this useful enough for you to pay for?'.
(These two should not be confused with the Initial Build,
a.k.a. Crappy-Piece-Of-Software-That-Crashes-On-Doubleclick. That's
just the first build of the source, after you've set all the processes
in place. It's only there for developers to debug and QA to snicker at.)
Now here's the tricky bit: You've done it. It's a success. You want to
go ahead and do the Real Thing (tm). So you spruce it up, stuff it in a
version control repository and start putting in the missing bits.
Wrong!
What you do is take a good hard look at it and throw it out. Well, OK maybe you keep it around like an old dog around the fire -- but you most definitely do notbase
the real thing on it. You take what's in your head -- all the
accumulated knowledge about the issues with the implementation -- and
use them to build it properly. From scratch. With processes like TDD
and architecture design and version control and release scope and
schedule all decided up front, based on your increased understanding of
the problem domain.
This is what management seems to be incapable of comprehending
and the reason for this acrimony. The normal thinking for managers
seems to be: "He spent 3 months on
this, costing me money. He needs something to show for this, something
I can kick. I can't kick the increased understanding of the problem
domain in his head (although I'd like to). Therefore I'll click like a
leech to the one tangible output he had, and we'll call is version 1.0".
Management, when faced with the need for a prototype, invariably end up saying to the dev team: "do it like a prorotype, but when we're done we'll call it the initial build".
They are then immensely surprised, 6 to 12 months down the track, that
the shoddy piece of software the dev team is crunching out is, well,
shoddy. There were no processed upfront. The base is ill-concieved and
not architected, no changes can be made in a reasonable time, any
change that do get made cause so much havoc that the dev team is
continually whimpering.
From a more formal risk analysis point of view, this is the equivalent
of 'none'. You had the idea. You kicked it around in a few meetings. And then you just did it!
You did not investigate the costs, issues and risks of the actual work.
By turning the output of the investigation -- the prototype -- into the
first build, you just effectively skipped the risk analysis. You never
looked at the analysis and decided what approach you're taking, you
just did it with no real planning.
Not that I have a solution for this, except a LART judiciously applied to management.
Previous Topic
