I just want to show a simple illustrative example.
Consider this musical instrument:
Consider this musical instrument:
It is a ukelele. It has 4 strings, it has frets, tuning knobs and that wooden box with a hole in the middle. Suppose I were to tell you that I wanted to upgrade this instrument by "just" making it longer, and adding two strings. I'd be asking you for this instrument:
You will recognize this instrument is a guitar.
I had a conversation much closer to home yesterday. Months back someone I know bid on building a system that consisted of database, data collection application, and an analysis module. It was for a lot of money and to save money the buyer opted instead for just the database.
Also, the buyer decided to bring the data collection application in-house.
Trouble was that the buyer's staff proved unable to do it in-house. So they went back to my friend to build them something to show what the data collection application would look like. And as you can probably expect, the buyer is now complaining about the limited functionality of the demo.
"Can't you just build up the demo into a working system?" The answer is yes, but it is also more expensive.
Consider the problem of upgrading a ukelele to a guitar. The stresses on the body are a a LOT greater in the guitar, because you've got half-again more strings, and you've got a much longer span over which those strings must be tensioned. You can't just bolt on two more tuning knobs and patch the neck of the thing to make it longer, and wider. All the strings have to be replaced, because all the old ones are too short. And the box can't just be patched, it has to be replaced.
That's what my friend and his client's software has to deal with. Sure, it looks like all you have to do is fix a few defects, but the problem is deeper. There are software equivalents of loads and stresses that have to be engineered. Little hacks that might look right in a demo to a bunch of managers can't bear an operational load.
One of the central problems of software development is visibility. You can't see what's wrong unless you know what to look for. And the warning signs are easy to ignore.
So, next time you see a pre-launch demo that looks OK, ask yourself, "Is this a ukelele or is it a guitar?" And if you need a ukelele, expect to pay the full price of a new guitar.
And it takes special skills to gain that visibility. If you had a magic machine that would perfectly depict the design of your current system, scoping in or out at will and showing as much or as little detail as you chose, it could still be utterly meaningless to your customers, who lack the fundamentals to understand what they're seeing.
ReplyDeleteIt's much like doctors in that way: they can look at scans and lab results and see conditions and diagnoses that are obvious to someone trained, but inexplicable to the patient. They have to translate their knowledge and observations into terms that the patient can understand before the patient can make an informed decision. And that's when the diagnosis is KNOWN. It gets far worse when the diagnosis is a mystery. Try explaining that mystery to the patient.