How to prove writing specifications beats code cowboys?

Asked 2009-02-23T22:27:16.127

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!

specifications

Edit Report

4 Answers

the goal is to write the right piece of software.... specifications is just one tool to try and find / define what the right thing is.

I think as a group it needs to be decided how you go about building the right thing and how you communicate that amongst everyone.

ie, focus on the real problem and then get shared agreement about how to solve it. Rather than say, "here's a solution to a problem, lets do it!", that often doesn't get a lot of buy in from everyone. It could also be that specifications are not quite the right thing to solve the problem either.

answered 2009-02-23T22:36:48.630

It usually takes time - and that is always the problem.

EDIT:

For your own company, I mean your friend, needs to document whenever something had to change and a spec was not available. Whenever a spec or docs would have saved time, record that event. Record the amount of time spent (both by the person researching and the person (if any) who was asked, helped, etc. Then you need to do a cost/benefit analysis of whether the time "saved" initially by not doing a spec was worth not having it when it was needed.

In some cases it probably pays off to write one, and you may find other cases where it is not "needed". In practice, the payoffs are potentially so big that it is always best just to have that done in the beginning.

Now - the caveat:

You may have reluctant people. Don't try to convince them just yet.
You need a repository that is standard use - it does not matter where or how, but it HAS to be consistent and well-known so they can be found
they have to be kept up to date and maintained

answered 2009-02-23T22:38:40.920

Just, tell your friend they have to avoid going to the other extreme where nothing could be done until the spec is perfect and 100% complete . And the coding delayed each week because someone added something else to the spec. There will be times where that approach could take 2 - 3 months and after which someone at the high management level will get very upset and will say "I don't care, I just want the product done" and the situation will be worst.

You can get the best of both worlds by keeping the flow agile ( weekly review, deliver early, quick look ups etc. )

answered 2009-02-23T23:19:14.987

Specs IS the waste of time. Most of the people who will use the software can't tell what they want but they can tell if what they get is good enough or not.

Prototyping rarely works for the same reason, they can't tell if this feature is not done yet or it won't be done at all, so they kind of go ballistic telling you it's all wrong and you should redo everything when actually they need just a quick tweak. Or they would tell you it's all good up to the release point when they finally would realize it's not usable.

The best way to design is to go out there and see how they used to do things and try to fit your application into theirs work flow. EVERY team member should do that.

I'm not saying you can't write requirements down but showing them to your actual users has no point. And you can very well hold all the spec in your head if you working on the feature alone.

In brief: don't write specs, spy on your users. Make sure all team members do that.

answered 2009-02-24T01:30:56.293

How to prove writing specifications beats code cowboys?

4 Answers

Your Answer