In their book The Pragmatic Programmer Andrew Hunt and David Thomas discuss what they term “Software Entropy”. By this, they mean the seemingly unavoidable and ever increasing disorder and decay in a piece software. They draw a parallel with the Broken Window Theory, described as follows:
In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict .
A broken window.
One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment - a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.
Their conclusion is that Software Entropy, or Software Rot, is primarily a cultural problem. One bad piece of code can start a process of decay that ultimately results in a horrible piece of software held together by the proverbial duct tape and chewing gum, and that collapses when someone in a room nearby sneezes too loudly.
However, while software rot is an unfortunate reality, and crappy software its sad result, I think Hunt and Thomas fail to cover a potentially far more important cause: Software Engineers not having a clue. Not that SE’s are incompetent (well, there’s that too, in some cases), but because for a variety of reasons they simply do not know enough about the overall design and philosophy of a piece of code.
When a new piece of software is developed there is always a design: a set of assumptions and ideas, a philosophy, that together determine how the code and the abstractions it models should be structured. This can be implicit, without any documentation being written, or it can be the result of a lengthy, deliberate process, but it’s always there.
As long as the initial designers are the only ones writing code, it will stay true to this design. But as soon as other people get involved, software rot sets in. These new people did not go through the same thinking process as the natives. They did not start from scratch, and did not go through the process of increasing understanding of what needs to get built to come up with a coherent set of ideas that form the foundation of all good designs. And one thing is certain, if you were not there from the beginning, reaching the same level of understanding as the original author of why a piece of code was written a particular way is HARD.
So this is where software rot sets in, when a project grows beyond the small core team that laid the initial foundations, and people are tasked with making changes in a piece of code they are not intimitely familiar with.
Fixing this problem is also hard, but here are some measures that can, if not prevent, then at least reduce the severity of software rot.
Make code reviews a mandatory step in the release process, train people how to review, and establish a clear set of coding guidelines people can use when reviewing. Also, make it a policy to include someone who is “intimately familiar” with the code in all reviews. Code reviews can be a drag, especially in the beginning when large swathes of completely new code are checked in almost daily. It is one of the best ways to improve code quality though, as the knowledge that someone else is going to check your work is a great motivator not to cut corners.
As an added benefit, code reviews help spread knowledge about the code-base, which improves shared code-ownership, which is a Good Thing.
In your coding guidelines, include rules about commenting code, and make it mandatory to use something like JavaDoc. This forces people to structure their comments in a uniform way, increasing readability across the code base. It also allows you to generate a hyperlinked set of documentation which essentially acts as your detailed design documentation. If your build environment is up to the task, build the documentation on a daily basis and make it available to developers, so they always have an up to date reference guide.
Coach New People
When people are added to the team, take the time to properly initiate them in the code-base. This can be done for example through workshops, where core team members explain the design and ideas behind the software. When they start working on tasks, carefully review their work with attention to violations of the design philosophy, which can point to gaps in their understanding of the software.
Hire the Right People
This may seem self-evident, but many organisations are still not aware of the fact that there are enormous differences in productivity between “average” and “great” programmers. Great programmers can be so much more productive because of their ability to quickly grok a piece of code. Much has been written on this subject, so no need to repeat it here.
These are just a few measures that can help reduce the effects of software rot. In general, software rot sets in when the code being written violates the principles of the design. It is my firm belief that a failure to educate people when they first start work on a project, and a failure to enforce application of the design principles, lead to such violations. The measures listed above attempt to reduce such violations by increasing everybody’s understanding of thought processes that led to a specific design.