Programmer Musings

We can't do that.

I probably shouldn't be, but I'm surprised how often I have heard the statement We can't do X in our environment... where X is one or more of the following:

• version control
• automated testing
• unit tests
• design
• testing
• object oriented programming
• bug tracking
• warning-free compiles

In almost every case, the person has claimed to understand the issue and to realize that the practice in question might really help. But, we can't do that in our environment. Quite often the reason is cost. Yet, the same people will complain about the cost of maintenance and support.

Another argument seems to be that this environment is unique in some way that prevents that practice from working. This argument is almost always supplied for suggestions about testing or automated testing. (Although I know of one case where it was used as an argument against version control.) This argument seems to be more likely to come from a technical person than the other argument.

As near as I can tell, there are only two things preventing the use of these and other best practices in a given company.

• resistance to change
• no business case

Any other reasons are usually excuses that are trotted out to cover the fact that no one wants to admit to the first reason. Any change to an established process makes people nervous. Even if they know the current process is broken, many people fear attempting to change the process on the chance that we might make it worse. What makes it the more difficult of the two is that you will (almost) never be able to get someone to admit that this is the reason they don't want to try a new process.

On the other hand, there are some who seem to delight in using this excuse. These are the our process works so there's no need to change it people (or, in some cases, our process may not be perfect, but the others are worse). For these types, their process works, period. Even when someone can show that the process breaks down, they will argue that the process does as well or better than any other process would have done in the same circumstance. This is actually a religious issue and there is no sense in trying to argue with these people.

The other real reason for not using best practices is the lack of a business case. Although programmers may be swayed by the technical merit of each practice (or at least the novelty of trying a new approach), management needs a business reason to make a change. Even the best of practices will generate a temporary loss of productivity as people adapt their work to use the new approach. There may be some time spent in training. Some time that went to head-down coding will now go to the overhead of learning and using a new practice.

The business needs a justification for this loss in productivity. This justification needs to be specific, not just empty promises. The annoying thing is that other changes that amount to fads or the methodology of the month seem to be imposed with almost no justification. The difference here seems to be where the idea originates. An idea coming from high in the hierarchy is its own justification. An idea from the bottom requires a real business case.

Unfortunately, I don't have any good answers on how to make this case. My skills do not seem to be well suited to making the kinds of arguments in the correct form needed to get these ideas accepted by management. If you do, I wish you all the luck in the world. In some cases, you can wear them down or implement the new process in a small project to show that it works. That approach does not always work, and can sometimes be detrimental to ongoing employment.