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.
