Most of my career has been spent in some kind of software development role, either as a tester, developer, manager or executive. One of the things I’m fond of telling managers and teams is that I have two rules about software development process:
- We will always follow our process.
- We will never do something stupid just because our process tells us to.
Ideally those two rules are never in contradiction, but in reality there are occasions when they are. I remind managers that they are generally paid a lot of money to figure out what they should do. As with so many things in life, a pragmatic, balanced approach is usually the best approach.
If an organization takes the time and effort to develop a software development process, then we can safely assume there was good reason for its development. Some worthy objectives are reducing wasted effort aligning development activities to market or organizational demands and ensuring efficient allocation of funds to the most important projects. You can no doubt think of several other good reasons to establish such a process. With any or all those reasons as motivation, exercising some discipline about following your process seems wise.
However, the process in and of itself should never become the organizational equivalent of a sacred cow. No process can anticipate the nuances and needs of every subsequent project. Maybe a commercial job needs to run beta level code. Maybe the process calls for two hours of paperwork when a customer demands a bug fix in 20 minutes. Perhaps the process was only designed for large multi-month efforts and the organization needs to run a three-week project.
In such cases, a fanatical commitment to process discipline for its own sake may not actually be in the organization’s best interests or advance the objectives that the process is intended to serve. Sometimes it is, however, and knowing how to tell the difference is when managers earn their paycheck. In some cases, management at all levels needs to display flexibility and focus on accomplishing the goals of the project and producing working software even if they must violate their own process. When this happens, the organization must conduct a follow-up to assess what happened and why and decide how such a situation should be handled in the future.
In other words, treat a defect in your process the same way you’d treat a defect in your code. First, fix the bug and get your system working. Second, identify the root cause and prevent the bug from recurring in other projects.