Developers Cannot Code Ambiguous User Requirements
In this post, I want to convince you that writing unambiguous user requirements is non-negotiable. Speaking as an old developer, I can authoritatively state that developers do not deal well with ambiguity. The reason is very simple. We cannot code ambiguity. The beauty of bits is that they do not waffle. If my program says the sales tax is 5.6% instead of the legally mandated 6.5%, the math works just fine every time. That does not necessarily mean that the outcome is satisfactory. Matter of fact, there are probably a whole slew of business managers, accountants, government agencies, and tax attorneys who might maintain that the law ought to take precedence over my program. The problem is, they cannot change my program. I can.
Developers and Real People
A second trait of developer-minded individuals like me is that we don’t deal particularly well with people. That is presumably because they (humans) are not as predictable as my other friends and allies (computers). For instance, the computer does not randomly select the aforementioned sales tax rate (unless I programmed it to do so). Every time I ask it, it will reliably respond with the same number. Computers are notoriously stubborn, but very consistently so.
Developers and the Geek Syndrome
Thirdly, developers like me tend to be geeks. What does that imply? In his book “The Inmates are Running the Asylum” (which is required reading for anyone who wants to communicate with a developer), Alan Cooper observes, “A geek would rather be right than rich”. (A trait which, my tax accountant, my banker, my spouse and all of my business partners can testify is true and apparently unchangeable.) This basically means that, once I have understood a user requirement, other interpretations might be possible, but mine is the only right one.
The Combinatorial Explosion
Taken individually, these three traits (I do not deal well with ambiguity, I do not deal well with people, and I would rather be right than rich) might be simply irritating. Together, they are a sure-fire recipe for conflict. What they really mean is that if you give me a user requirements that contains any ambiguity, I will resolve it to get my code written. Given that I do not deal well with people, I certainly am not going to ask them any questions. I do not want to give them cause to think that I am ignorant. Besides, I know that I’m smart enough to figure out what they meant without bugging them with silly questions.
So How Bad Can It Really Be?
Of course, once I have figured it out, rule three applies: I am a geek, ergo I am obviously right. And don’t you non-geeks come trying to tell me that I’m not because I can explain to you in excruciating detail (I live for minutia) why I’m right. I don’t care what you meant when you stated the user requirement, the only thing that is important is what I understood when I read it. After all, that is what is coded and computers don’t lie.
The Final Analysis
The irrefutable consequence of this set of circumstances is this: if you want to get a solution that meets your needs, get your needs figured out first. If you need help with that, talk to your analyst (business, system, or other). I do not have time to help you with that; I am too busy writing code. You will get a solution that works for you if you give me a clear, concise, unambiguous set of business requirements that I can only interpret one way. If my way is your way, too, this just might be the beginning of a wonderful friendship.
Remember, requirements rule!
