It seems to be pretty rare for people to consciously undermine any established system that has been put in place to develop software. At least, few will admit doing so. What usually happens is more subtle, an erosion over time of the good practices that make the software development machine tick.
A lot of software teams start off with wonderful intentions. There is a conscious decision to put in place a collection of practices that will help them build great software, within reasonable expectations of time and cost. Sometimes documented, sometimes not, but at least there was some gray matter applied to try to ensure the right things would be done.
Unfortunately, though, life quickly gets in the way. Erosion usually occurs in the name of time, with an unconscious degradation of quality.
There might be a quick patch needed in the field, and there just doesn’t seem to be the time to shore up the fidelity of the system afterwards. This can soon become a cascade of patches that undermines any fidelity the originally configured system may have had.
Perhaps the decision will be made to skip the peer reviews on this module: “Bob knows this part of the system inside and out and there’s no way we could contribute.” Actually, even those brand new to the organization or totally unfamiliar with the product can contribute significantly to a peer review. They’ll ask the naïve questions that expose the underlying assumptions that really need adjustment.
Sometimes it happens as people join the team without a deep understanding of the agreed-upon approach that has been established. When people start, there’s discussion of the business and product, but rarely an explicit discussion of process (except, of course, for how to make the coffee). This is where documenting your actual approach comes in handy (rather than pointing people to some theory that is never applied).
Some of the deepest erosion occurs when push comes to shove for a project’s schedule. “Let’s skip that big chunk of testing and hope that nothing bites us, the customer is screaming for the system”. This can hurt you either way: if you get away with it this time, there will be some serious pressure to not even schedule the time for the next project. If you do get burned this time around, there can be some serious ramifications.
Regardless of how it happens, skipping steps that can save our bacon is rarely done with quality as a consideration.
There are often comparisons between a software development project and a manufacturing production line. For most software projects, though, the comparison should be to the design of the production line, not the line itself.
In a manufacturing plant, on a production line, it’s pretty clear what happens when a piece of the system is removed – the wheels can literally fall off (trust me, I know this first hand from a summer job of shuttling new cars across the border for Chrysler years ago). The production line is built to produce a quality product, and is optimized so that this product can be built efficiently. Once in a while one of the pieces of the assembly will break down, but nobody really thinks that removal of one part of the system, in the name of saving time, will turn out a good product faster – unless of course, they are consciously optimizing the assembly line.
So it goes in software. It is critical that we decide how we are going to build our software, and put in place some mechanisms that will allow us to ensure that this originally designed system remains intact. As we are tempted to make changes to how we build our product, we need to be focused foremost in the fidelity of the development process, rather than merely looking at how to get the product done more quickly. We need to build in checks and balances – retrospectives at the end to be sure, but also intermediate checks along the way – at key milestones, periodically if necessary, that check the fidelity of both our product and the approach we use to build it.
We need to avoid erosion of our system for development, regardless of the weight. – JB