In the beginning, there is a Problem.
Customer knows that the Problem exists, but can't tell exactly what the Problem is.
So the Customer goes to to a Programmer and asks him [or her, of course, but let me keep this simple]: "Can you build me a program that does That?"
[Here lies the original sin. Customer never asks: "Can you help me solve the Problem?" Because of that, Programmer is writing a program to do That instead of program that does This.]
Programmer says: "I can," because we programmers, by our nature, want to believe that we can code anything. So the Programmer goes to work and he works and works and although he has no idea what he is working on and how it should be built, he makes the Version One. It is merely a research project, a tool that allows the Programmer to understand the problem (not the Problem, just the problem of coding a program that does That), but the pressure of the modern world forces him to deliver it to the Customer.
Of course, Version One is unusable. After all, it was merely a sandbox where the Programmer tried to understand the problem. So the Customer pretends that he is using it and from time to time orders a small change, just to make the Programmer think that his software is being used.
After some time, Customer starts to think that he should really get something useful for his money, not just the unusable Version One and thus commissions the Programmer to write a new, improved version. Mind you, the Customer still hasn't a faintest clues what the Problem is, and so doesn't the Programmer. Even more, Programmer still has no idea that he has to solve the Problem. His task is to write a program that does That.
Still, something has improved since the day 1 - Programmer's understanding on how to write a program that does That. So he goes and codes much better program, which is built on his previous experiences. And thus the Version Two is born.
Version Two is much better version. It actually works. It doesn't look like a five year old has put it together in one afternoon and it doesn't crash every five minutes. And so, the Customer starts using it. And after some time, he sadly recognizes that the Programmer has indeed written a wonderful software that does That, but that this, alas, doesn't help him solve the Problem at all.
But now the Customer can finally tell the Programmer what the Version Two should do differently. And the Programmer listens and finally says in awe: "You mean that it should do This instead of That?!? Why didn't you say that in first place?"
And thus, the Version Three is born. It is written well. It solves the Problem. The Customer is happy. And the Programmer lives on to fight yet another battle.
This I believe.
Which is why a good developer (as opposed to just a work-a-day programmer) will always ask "Why?" whenever a customer asks for something.
ReplyDeleteCustomers ask for solutions - they understand their problem but they do not understand how to solve it, otherwise they would solve it themselves.
Here's the deeper problem: The move away from structured methods toward more "agile" processes actively PROMOTES a "code first, ask questions later" approach.
The supposedly slower structured approach involved detailed requirements gathering upfront, so the important "Why" questions were more likely to be asked.
Note that I do not say that agile processes PRECLUDE rigorous requirements gathering, only that they do not encourage or tend towards it.
Neither do I say that the slower structured approach was invariably more successful overall, only that it has/had a tendency to be more successful on the specific point, of understanding of the problem.
Which is one reason I despair with the current love affair with "expressing the problem" in languages.
The REAL problem in software development is not being unable to express the problem, it is in understanding what the problem actually is.
Until you get that right, being able to cut-code quicker, in fewer key strokes and in ever more obscure and increasingly indecipherable incantations isn't going to help you deliver the RIGHT solution. It's just going to enable you to deliver more wrong solutions more quickly.
imho
Unfortunately sometimes even version 3 is not the last. The programmer now knows how to write a programm that does "That" but version 3 is supposed to do "This", which might be a totally unrelated approach.
ReplyDeleteFunny that you should bring this up... I just wrote a short snippet more or less on the same topic...
ReplyDeleteAsking questions is the key to success.
This is news?
ReplyDelete"Throw the first one away" said Fred Brooks, in his classic "The Mythical Man-Month", published in 1975. And he was talking about his experiences developing the IBM OS/360!
Some things should be burnt into programmer's brains at birth.
To me it was not just news, but an epiphany.
ReplyDeleteNot the "throw the version one away" part. I've known that for a long time. And yes, I've read the Brooks. It sits firmly on my closest shelf and I'm recommending it to all new programmers passing by.
It was the second part that was a mystery to me - why does the second version usually fail.
In Fred Brooks' day, a team of guys in labcoats interpreted the user requirements and entered the data. They were the user interface, so to speak.
ReplyDeleteToday, the user interfaces are the GUI which essentially reflect the workflow, somthing conceptually separate from the individual routines inside the program.
Getting the handling right makes a program that strictly fulfills the customer's spec into a tool that actually is useful to the person sitting at the PC. That, in my experience, is why we often experience a third iteration.