Can We Afford Software Process?
In small entrepreneurial companies, the most critical things are speed and flexibility. We must be able to move quickly, react to both opportunities and threats, and make new product available to customers on a regular basis. In an environment like this, can we afford to spend the time to focus on developing and improving our software development processes? And can we afford the overhead involved in following well-defined processes?
A better question would be:
Can we afford not to address our software development processes?
The most precious resource we have is our people’s time. Every moment of their time must be focused on productive work, or our success is in jeopardy. This is one of the main reasons we can’t imagine spending time on software process improvement. But how much of our people’s time is actually productive?
Every mistake, every missed hand-off, every case of duplicated work wastes this most precious resource. And if we are honest in our assessment, these sorts of things waste our people’s effort on a daily basis. Sometimes there are horrendous screw-ups that set us back by days or weeks at a time. But the more insidious effort wasters are the little errors that happen over and over again.
Far from wasting precious time, high-quality processes help our software development organizations to be more efficient, more agile, and more able to produce good products quickly and at lower over-all cost. How? Let’s look at each of the biggest wasters of development time to see how high-quality processes will reduce or eliminate them.
The marketers, designers, coders, testers, and writers all read the same words in the requirements document, but somehow envision different products. Lacking a common understanding, each blames the others when the pieces don’t fit together or the final product "isn’t what was specified". But the bottom line is the rework (wasted effort) that is required before a working product can be released.
A fine-tuned requirements management process will assure that the requirements specification says everything it needs to, and that all parties have the same understanding of what it says. A few additional hours of attention to the requirements process can avoid days or weeks of rework later in the project.
Too often, we have some developers who are constantly over-loaded and others with much less work to do. And as we approach the release date, heroic effort by everyone seems to be the norm. Our development managers are technical folks, not administrators. This means wonderful attention to the technical details of the system, but it also generally means leaving managing the critical path and resource balancing to Microsoft Project.
By assuring that our project management process is oriented to the needs of our technically-focused managers, we can assure that attention is paid to important issues without incurring the overhead cost of administrators. The time spent developing the right project management process will pay huge dividends in greater efficiency of every project we undertake.
Two developers are working on seemingly unrelated features, but end up making conflicting changes to the same module. Everything seems to be going fine … until integration! Then the code that everyone thought was working has to be reworked (maybe in significant ways) before the system can be assembled.
Configuration management is far more than checking code into a code management system. Assuring that everyone knows who is doing what to which code and avoiding collisions takes some time and personal discipline. But that effort is more than repaid by avoiding the rework that results from collisions.
We understand what we must do to build the functionality that has been specified, so we dive in and build it. But surprises inevitably pop up. Something doesn’t work as we expected, or the pieces don’t fit together like we planned. And in the end, we find ourselves in a losing race with the clock to hammer together a system that comes close to meeting the requirements.
Well thought-out architecture, design, and review processes coupled with judicious use of prototyping, spiral development and other non-traditional methods will assure that the only surprise we encounter is that the whole thing came together so easily!
"The evil at the end", testing is that part of the development project that always seems to hold us up. We have the software built before our release date, but testing just seems to go on and on!
In fact, testing only takes a long time because of the bug fixing (rework) and re-testing (rework) that we end up doing. Peer review of code before testing begins has proven itself to be a very efficient alternative to testing the defects out of the product. This doesn’t mean that we can dispense with testing; rather it means that testing becomes a quick check to be sure that we’ve done the other things well. Carving review time out of the development schedule is rewarded many times over in reduced testing time and on-time releases.
The types of waste we have been talking about are often invisible to senior management, and sometimes to first-line management. Even the engineers themselves may view them, not as a problem to be fixed, but as a normal part of the job.
These numerous cases of wasted effort are a gold mine of opportunity! By investing a few hours of introspection, and a few more hours figuring out how to avoid the waste, we can achieve significant improvement in the organization’s over-all effectiveness and responsiveness. This small investment of effort in software process improvement can yield returns many times greater than the investment, simply by making significant reductions in wasted effort.