Be a Better Developer: 2 – Being a Janitor
This blog post is part of a larger series named “Be a Better Developer”. You can check out the intro, “Stop Being a Code Monkey” to get started from the beginning. Each post will have a link to the previous ones and a final summary post will contain links to all entries in the series.
Usually, multiple people work on a given code base over time and often the code we work on isn’t our own. We are fixing bugs and adding features to code that has been around a while, originally written by others. Or maybe it was our code at first, but since we last touched it many other hands have been in the till. This has the potential to lead a very snarled code base if you don’t make the effort to keep it from happening. I think we’ve probably all come across a code base we can tell many people have touched just by reading the code. As developers we find that we need to have the janitorial skills that can help us prioritize what messes need to be cleaned up immediately, what can wait for later, and what parts we need to do that “daily once over” on so that they don’t get out of control.
Being a janitor is hard work. The job isn’t glamorous and is, many times, thankless. When was the last time you said thank you to the janitor in your building when you saw them mopping a floor or restocking the toilet paper in the bathroom? For most people I’ll bet they’ve either never thanked a janitor or they simply can’t remember when. This is because we just expect them to be there cleaning up after us and making things nice. We just assume that we can make a mess and someone will clean it up. This isn’t always the case in a code base. In fact, if you don’t try to keep things tidy as you go the code base can quickly become a mess with a perception of no time to clean it up as deadlines loom and new features are stacking up on the backlog.
Broken Windows
If you leave ugly code, people will be more likely to propagate it. This occurs for a few reasons, but there is a good corollary of how it gets started from a study on, of all things, urban crime. James Q. Wilson and George L. Kelling wrote an article in The Atlantic Monthly entitled “Broken Windows” which detailed a phenomenon of a progression of crime based on the condition of the environment. Here is an example: if a window is broken in a building and no one repairs it there is the perception that no one cares about the building. Over time this perception means that there is a higher likelihood for more windows to be broken, the building to be broken into and if it happens to be vacant, for homeless to take up residence. This doesn’t just affect the building, but the perception often gets extended to the local environment or neighborhood. The perception that no one cares can lead to the spread of petty crime.
The Broken Windows article was referenced in a Pragmatic Programmer article on software entropy and also referenced in Clean Code by Robert Martin. The idea was that if we have a codebase that becomes a mess and is not well thought out there is a perception that no one cares about the codebase and thus it will only become more snarled. I know I’ve looked at several applications that are the equivalent of that run down building and thought, why am I putting all this effort into something no one cares about? I don’t know many developers who really want to work on what one of my client managers refers to as “Craplications”.
Technical Debt
Ward Cunningham introduced the concept of the “debt metaphor” quite some time ago. Mr. Cunninghams’ original intent behind this analogy was that on a project they could choose to press forward with what they knew about a specific issue or problem space in order to get the software out the door. Once it was out the door they could see how it was used in the wild and thus further their understanding of the problem. They could then refactor the software using this clearer understanding of the problem. His analogy was that on the project they could take out a little debt (knowledge that they would need to change the application software later), while getting the benefit of shipping earlier. Each time they discussed the problem without shipping was just paying the interest on the loan. Then, after the problem was better understood, they could come back and pay off the debt by changing the software to better resolve the problem. Note that Mr. Cunningham was very specific that he didn’t advocate writing unclean code at all, only that in some cases you need to press forward with what you know at the time, taking out a little debt that you can pay off later when you better understand the problem.
For many bloggers and developers the idea of technical debt has taken on a different meaning. My first understanding of the term was that when developers choose to take a shortcut or “throw something together” they are taking out the loan. Over time more of these types of decisions cause the developer to continue to take out more and more debt. If the code base is snarled and you need to add new features many times these decisions lead to an increased cost to add the new feature, which is much like paying off the interest (but not the principal) of the debt. Finally, when the cost of the loan is too great someone decides they need to pay off the debt and a re-write is slated. This version of technical debt resonates with me as much more common than Mr. Cunningham’s original concept of the debt metaphor.
Mr. Cunningham’s version requires that developers are making a specific decision to press forward with the solution to a problem with the knowledge they have on hand, but doing so using good design practices. Sadly, I think it is more common that developers press forward with a solution, but take shortcuts and implement hacks along the way. It is unfortunate, but I think we all see this and, as much as I’d hate to admit it, I too have done this in my career. Producing a solution or product that is filled with snarled, unclean code just piles on the debt that you, or someone after you, will likely have to pay off. We are always going to be in rush to get our solution out the door (first to market, meeting a trade show deadline, etc.), but if we take the time to ensure our code is clean then paying off the debt will be much easier.
To be a good developer you have to be a janitor.
Again, being a janitor is hard work and is often times a thankless job. People just expect things to be clean. As a developer we need to learn how to keep our code bases clean so that they don’t suffer from the perception that the concept of broken windows implies. Also, as we push forward with our solutions we need to focus on keeping our code clean so that our technical debt is easy to pay off once we understand the problem space better.
In the next post in this series I’ll provide a few ways you can tidy up after yourself and become a better developer by being a janitor.
Previous Posts in this series: