So I have a problem. Or rather my friend has a problem, since I would never write about my company on an internet forum.
At my friend’s company specification writing is, shall we say, a little underused. There’s a deeply ingrained culture of writing code first and asking questions later, whether it’s for a library routine or a new tool to inflict on their long suffering designers.
This of course leads to situations where functionality is partially correct, incorrect, or just completely missing (‘oh, just save before trying anything you may want to undo’). This usually results in a loss of productivity for those poor designers, or beta periods where bug-fixing is largely spent implementing things correctly.
My friend’s found his suggestions of writing (and testing against) specifications to be generally well received. Most of his colleagues have embraced the wonderful feeling of discovering false-assumptions on paper, instead of at 11pm on a Sunday in the middle of beta. Viva La Revolution!
However there are a few who poo-poo anything that stands between their task and a keyboard. They laugh at the thought of actually designing anything, and write code with merry abandon. Mostly these are senior, long employed developers, reluctant to ‘waste time’.
The problem is that this second group of heretics invariably produce things (or at least something) quicker than the first. Subsequently this becomes justification along the lines of ‘It’s pointless to write specifications for something as simple as an image resizer! Oh and those bugs where width!=height or the image uses RLE just need a few tweaks’.
And now the question 🙂
Other than saying ‘told you so’ at the end of a project, what are some good short-term ways to demonstrate how the practice of writing functional or technical specifications leads to better software in the long run?
Cheers!
This is pretty difficult since office culture and work habits are very hard to change. If you are really serious about this though, try to get management to agree to a trial where specs are used for a small project/module, and maintenance costs (time, bugs, etc) are quantified over time.
You may not get the other developers on your side this way, but $$’s are easier to understand than more abstract dev practices. The management of the poo-poo’ers are responsible for that group’s continued employment and performance reviews, so that is one way to convince them to change, or to have them work somewhere else.