I just spent three days inventing and writing some complicated code according to the specification document that I got from my client. I just showed the result to two guys (who wrote the specs), and now they discover that it is not what they intended. What I built was exactly according to what's described in the document, but only now they discover that what they wrote is not what they wanted...
So I can throw away what I have been working on for the past three days and they have to re-think the specifications, which I'll have to implement later.
Fortunately I'm not responsible, but I still hate it when I discover my work has been for nothing...
Bert Bates wrote:Did the specs you received make sense to you?
Did you discuss the specs before coding began?
Yes, they made sense to me. The specification people know more about the business than I do, so most of the time I assume that what they write is really what they mean. I've been annoyed before by the specs being too vague and open for different interpretations. I have reviewed the spec document beforehand, and this part of the spec seemed to be clear. But now, when they see what I made, they discover that it's not what they had in their heads. It seems that what they had in their heads was also insufficiently thought through (i.e. contradicting itself), so they have to go back and think again what it is that they really want.
It's not a big disaster, but I just wanted to vent because this particular thing was quite complicated to write, so I was glad when I was done - that made it extra hard to discover that I did all that hard thinking for nothing...
I think you are describing the standard case. I used to hate it, but now I expect it.
This is what drives Rapid Prototyping. You get an idea of what they want, build it, and show it, they hate it, but now you can talk about "how about if I do X"
and iterate a few hundred times.
Of course, the downside of rapid prototyping is that you usually circle back to the same place a few times.
Joined: Oct 14, 2002
Hey Jesper -
If I came across as harsh - I apologize. I like to play "Be the application" with spec creators - in other words, I like to run through use cases with them and imagine how the app is supposed to work before coding begins. Of course, that doesn't always succeed... but I do like the line "iterate a couple of hundred times"
Jesper Young wrote:I just spent three days inventing and writing some complicated code according to the specification document
Three days? And you are complaining?
The US FAA's AAS was a total failure.
"At $3.7 billion, the Advanced Automation System was one of the largest civilian computer contracts ever."
"The Advanced Automation System began, in concept, in 1981 and ended in 1994, “terminated for convenience” by the government. "
There were literally trailer trucks full of specifications.
Somehow it's nice to hear that one is not alone.
But hey, three days? Consider yourself lucky. Two years ago I worked on a project for about five or six months, where I said from the very beginning, that no one will ever use this application. The reply of the customer: I also would never use this application, but the market demands(!) it! But how do you know that the market demands something if you are not making any research before? And how can you then know how the application should look like if not even you are willed to use it? Unnecessary to mention that only a few testers saw my work. Wasted lifetime. But as long as I'm getting paid, I'm still a code-whore (even though I know that will change after a few of more such projects).
Wow. So lobbing a formal specification of a complex system over the wall, without looking back once, expecting that what you'll end up with will perfectly match up with what you intended, doesn't actually work? Now that's plain shocking. I don't that's ever happend before in the history of software development.
Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.