What does the spec say again?

Today I came across and logged a bug, which on closer examination turned out to be a result of an ambiguously-worded line in the specification rather than a simple coding error.

I mentioned this on Twitter during a mid-morning coffee break, and got two contrasting responses.

The first was that the written specification is just the starting point of a conversation between the Business Analysts, Developers and Testers over exactly what the system should look like, and constant communication will resolve any ambiguities as the development proceeds.

The other was that a developer should not be expected to question things in an environment where even the smallest changes require signing off from multiple people with different conflicting agendas. In such circumstances it’s easy to see why a developer might make guesses rather than ask questions.

My reaction to that is that if you’re trying to develop software in an organisation as bureaucratic as in the second case, you run the risk of ending up with software that’s every bit as dysfunctional as the organisation itself.

I’ve worked on projects like that in previous lives, with great long specifications written in great detail for the benefit of the developers who were supposed to implement the thing, but completely failed to give the business stakeholders any real impression of the actual functionality. But the stakeholders went and signed it off anyway, perhaps because they wouldn’t admit, maybe even to themselves, that they didn’t really understand the thing. Needless to say that project went horribly pear-shaped and turned into a nightmare death march as the development team were buried under a mountain of change requests.

Are there still organisations that develop software like that?

While I’m still in Waterfall-land, fortunately my current project is nothing like that. In the end, I got given the task of rewriting that bit of the specification to remove those ambiguities.

This entry was posted in Testing & Software and tagged . Bookmark the permalink.

One Response to What does the spec say again?

  1. I’ve certainly worked on projects like your pear-shaped deathmarch, particularly in relatively high-risk environments like financial services. I’m now in much more agile contexts, and I have to say, I do appreciate the flexibility that we get from frequent communication and empowered system owners.

    Having said that, I’m not convinced that it’s not the developer’s job to query unclear specifications if they notice them. It’s no more difficult, and much less expensive, to poke at them before coding than it is to drop the job on the tester at the end of the lifecycle. I don’t want to blame devs for struggling with dysfunctional working environments, but passing the hairball down the line just makes it worse for everybody on the project.