Fear leads to festering code
A recent post by Michael Feathers discusses budding code bases (http://michaelfeathers.typepad.com/michael_feathers_blog/2010/06/festering-code-bases-and-budding-code-bases.html). The idea presented is that code bases fester when new code is added to existing methods and classes instead of building out the code into new modules.
I am sure that you have seen code like that and you immediately blame the developer. They must have been a moron who didn’t have any idea how to design software right? Maybe not. The idea cuts right to the heart of development. Why does crappy code exist? If a few relatively simple practices and patterns exist that can reduce many of the headaches we constantly face then why are we constantly stuck with messy and tangled code? Like anything else, if there is a way to cut corners you can rest assured someone will. Which means that the problem isn’t a technical one where a language feature or an IDE tool would solve the problem. Much like security warnings most people would rather turn off the warning instead of letting the IDE nag them or they would find an even more elaborate hack to get around doing things correctly. The problem exists with the messy part of software development that no one likes to mention – people. In the end people are writing the code and the company drives the people. In order to find out why the code is bad you have to look at the company and the culture presented.
In many organizations there is a culture of fear which keeps the developer writing code just well enough to not raise attention. The people and process are setup in a way that you are rewarded if you don’t make waves and you are punished for thinking outside of company policy. You are not rewarded for writing clear and well designed codes but you are rewarded for slapping in new code and moving along. This culture keeps a constant level of fear instilled in the developer. Since no one tries to make improvements in design and structure you are constantly afraid that the change you are making is going to bring the house of cards the application has turned into crashing down. Like a frightened child who stares at the floor at their feet the developer focuses on the code closest to where they think the changes should go. Since there is no architecture in this fragile system it is impossible to tell when something doesn’t “fit” into the overall picture.
I commend Michael Feathers for so succinctly expressing what I constantly run across from large and small companies alike. But to those who want a technical tool to solve the problem – good luck. Until the company changes its culture and developers are allowed to be craftsmen the problem will remain. There are people out there who are writing clean code who have the same constraints as the people who are writing bad code. It up to the developer to make a choice and have the integrity to stand up and push against the ceaseless desire to create festering code bases.