Rather early in my career as a programmer I learned a few rather important characteristics about software development requirements as well as how important delivering to an end user can be.
Way back, more than 10 years ago, when people still argued if Internet could be used to do other stuff than transferring JPGs, me and a colleague got involved in a small project. We where supposed to convert an MS Access application to a web ditto. The whole idea was basically that more users should be able to run the application and future upgrades would be a lot smoother. The current application had a few know bugs and those should be addressed as well.
Smooth sailing
In those days fancy web frameworks weren’t available, JavaScript implementations in browsers were rocky and their compliance to web standards was coincidental at best. Even so, a couple of weeks after we kicked development off we were well on our way and it looked like we could meet the expected delivery date. We worked at rather comfortable pace and finished the project one week late.
The late delivery wasn’t a big deal, no something else was.
A couple of months later we had developed a perfect replica according to our specification and the web app was installed and ready to be used. I later learned that the fact it was a perfect replica was the actual problem. Apart from the obvious bugs we removed we hadn’t realized that there were some more serious flaws in the current implementation.
First Demo
The implementation of the process flow didn’t fit reality which forced the users to go through unnecessary steps and procedure to work around a major design flaw. This became painfully obvious when I sat down with the customer during a demo. At first I felt rather proud of what we had achieved during the weeks of development but as the demo drew to and end the users that where present got more and more agitated. They where supposed to be impressed I thought to myself as I started to break some sweat.
10 minutes before the end I was trying to sum things up as a lady said: ‘What about the work flow …’. ‘Yes, how about the issues with the work flow …’ another one pitched in. I was baffled; ‘Yeah, what about it?’
‘You haven’t fixed the work flow?!’
I hadn’t … because I didn’t know I was supposed to.
In retrospect
Looking back I can see how easy it would’ve been to start pointing fingers and blaming each other or even blamed it on poor specifications. But the specs weren’t poor, were they?
As a developer I thought the specs were great and I had a really good grip on what to do. Just make a web application out of this, this really really precise specification. This legacy app. And we did!
We really managed to implement it. But did that cut the mustard? No it didn’t.
I think I was being misled and fooled by the very precise specification, in this case we had a running MS Access application. Which to me seems very precise. We could see the GUI, all the buttons, the drop-down menus and by golly we even had a reverse engineered schema for the database. Could it be more precise than that? I didn’t think so.
Today I still see lots and lots of people trying to work out very precise specifications. They really put their mind to it and often enough they produce really precise specs. This is what I think leads other people to think they are correct. This much detail … this high precision, no one could be this precise without being correct, right?
A piece of advice
- Precise isn’t the same as correct nor accurate
- Don’t substitute specifications for conversations
And last but not least; Software is of no use unless it’s in production and making peoples life easier.
