In recent times I’ve done the unmentionable, the disgusting, the horrifying, the unheard of: I said “we’ll just have to change their requirement then” and “stuff the requirement, they just didn’t know what they wanted”.
When you make this sort of statement it almost becomes like the old western movies when the odd looking but well intentioned guy walks into the bar – the crowd falls silent, the tumbleweeds roll past outside, there’s just a faint noise of horses or insects outside and dead silence inside… Then the tough guy who’s been drinking at this bar for some time (and is quite possibly drunk on dirty whiskey) gets up from high seat at the bar and says “them’s mighty strong words, runt!”
Like many, in recent times I’ve been working in a environment following a waterfall-esque development methodology where upon developers are completely shielded from the end user (or perhaps its the other way around) through numerous layers of indirection and obfuscation (aka analysts, management, and expensive “requirements” documents). So what’s a developer meant to do when the gut says “something smells fishy here”? What do we do when we stumble onto that magical requirement that flies in the face of the rest of them or just won’t fit with the architecture that’s been built up around all the other requirements?
Initially when the feeling of inferiority (and a touch of rage) for having such impure thoughts had subsided I felt compelled to write about the fact that not all of our so called “requirements” are to be treated as gospel and to try to explain how certain situations called for developers to take drastic action by simply chucking them out or re-engineering until they were unrecognisable. Finally, it occurred to me that I too was falling into the old waterfall habits of blaming the “other guy”; in this case the analyst who wrote the spec. In reality, software development is about an evolution as a team and business toward the end product. It’s not just about building something to a plan, it’s about creating something, it’s about a delicate balance of art and logic. All this means is that if you don’t have the courage to communicate your problems then the whole team loses.
Some validation for your courage
When it comes to trusting the quality of a requirement Chad Myers makes the point beautifully in his “I don’t trust me” development methodology ideal (which is suspiciously agile and TDD) such that when it comes to requirements he says:
I don’t trust the customer or the target consumer for the software we’re building. I don’t trust them to know thoroughly what their problem is. I don’t trust them to be able to communicate effectively to me what picture of a solution they have in their mind. I don’t trust them to be able to know, beforehand, everything that they would need to have their problem solved to complete satisfaction. They will change their mind, remember things they missed mid-way through the project, remember that what they asked for earlier on was wrong and needs corrected, etc.
With these (rather cynical) realities in mind, it becomes quite clear that not everything in the precious requirements documents is to be considered gospel. It’s up to the developer – who has the most intimate working knowledge of the system to be proactive by seeking a solution that best delivers true value to the project.
Thinking and talking win-win
Realising that everyone involved in the team has different viewpoints (some perhaps flawed, invalidated by time, or less intricate than others) it’s time for you, the courageous one, to communicate your problem and reasoning. If a requirement can’t be done affordably, doesn’t fit your current architecture, is contradictory, is futile, or any other reasons then it’s up to you the developer to be proactive and start the conversation rolling. There are many project management solutions that all offer continuous and potentially cheap alternatives that won’t suck the soul from the developer who would have otherwise felt like going into battle in an David versus Goliath grudge match that would have resulted in re-estimations, benefit analysis, requirements revisions, or anything else that limits developers from actually being creative. My personal preference are informal communication channels such as a chat over your desk or during a daily stand-up meeting (where you can’t forget to occasionally invite those chickens). However, probably best avoid written media (email, MSN) except as an affirmation of your plan of attack.