Plans are nothing; planning is everything.
Dwight D. Eisenhower
People have a lot of faith in written documents, but anything written, whether it’s source code or use cases, will have flaws. That’s inherent in the nature of anything created by fallible humans. Unfortunately people often seem to want to ignore this fact. No one would write a thousand lines of code and assume there are no bugs, even if it was done test-first. But user requirements, coding standards, and process documents aren’t treated in the same sceptical manner.
We recently talked with a company who thinks that because of the amount of time and effort they’ve put into their requirements analysis, the actual implementation of the project should be a small matter, taking a fraction of the time spent on the documents. They were also interested in a new software product for simulating use cases, which they believe will mean even less time needs to be spent on development.
Sure, figuring out the customers intentions helps with a project, but if you’ve spent hundreds of hours making a document, and you have nothing implemented at all, it just means that you’ve spent thousands of dollars of your customer’s, and they have nothing to show for it. And the problems waiting to be discovered in the system, which can only be found by doing, are still there, basically adding negative value to the work you’ve done so far. (End result, $0 of value created – $N unexplored problems = less than nothing.)
Two ways written documents are used
- Excuses for not thinking
- Ass covering
Thinking, not following
If you believe in the written word and have absolute belief in the infallibility of the authors, then you have no reason to think about the problem yourself. This is the worst thing you could ask for from a good software developer. Blindly following requirements as given will inevitably lead to software full of features that don’t really match what the customer needs.
A good developer cares about the success of project. This means critical analysis of the project, questioning any requirements they feel might not be in the best interest of the customer. This can only be done by having something real that the customer can look at, criticize, and use for planning. A couple of meetings with a customer with delivery six months later loses this chance for more thorough analysis.
Sometimes this means that a project becomes something quite different from what was originally intended. (We’re experiencing this right now on one project.) Sometimes the project is canceled or put on hold. These are much better outcomes than spending the full budget (or two times it) only to find that you have a steaming pile of software that has little relation to what you really need.
CYA
A poor programmer will not assume any responsibility for the failure of a project. A poor project manager will hope for more perfect requirements for the next project.
I don’t think I’ve ever seen a project fail because of the technical skills of the developers, or the analysis of requirements. What leads to project failure is an inability to acknowledge either of the shortcomings in documents or technical effort, and an unwillingness to face and challenge the assumptions going into a project.
The lazy individual, when faced with a failed project, will point to the thoroughness with which they followed the procedures and use cases of the documentation and say, “I did my job perfectly. I did everything that was required of me by the documents handed to me. It must be the fault of something other for our lack of success.” And they will be able to find some one or some process that didn’t follow the written procedure and lay the blame for failure there.
Credit for this post goes to Shawn Crowley. These ideas are his. I just decided to write this post, when I saw he hadn’t done so yet.
