Leave It in a Better State
From Programmer 97-things
Imagine yourself sitting down to make a change to the system. You open a particular file. You scroll down... suddenly you recoil in horror. Who wrote this horrible code? What poor programmer had their way with this? If you've been working as a professional programmer for a reasonable length of time, I'm sure you've been in this situation many times.
There is a more interesting question to ask. How did the process let the code end up in such a mess? After all, far too frequently, messy code is one of those things that emerges over time. There are, of course, many explanations, and many war stories that people share. Perhaps it was the new developer. Asked to make a change, they didn't have enough understanding of how the code was supposed to work, so they worked around it instead of investing time to truly understand what it did. Perhaps someone had to make a quick fix to meet a deadline and never returned to it afterwards — moving on, perhaps, to make the next mess. Perhaps a group of developers worked in the same area of code without ever sitting down together to establish a shared view of the design. Instead, they tiptoed around each other to avoid any arguments. Most development organizations don't help by adding additional pressure to churn out new features without emphasizing inward quality.
There are many reasons why mess gets created. But somehow developers use these same reasons to justify not cleaning up anything when they stumble across someone else's mess. Easy? Yes. Professional? No.
It's rare that a horrible codebase happens overnight (those are probably those demo systems thrown into production). Instead, our industry is addled by systems slowly brought to their knees by programmers who leave the code without any improvements, often making it just that little bit messier over time. Each small workaround adds another layer of unnecessary complexity, with the combined effect of quickly escalating a slightly complex system into the monstrous unmaintainable beasts we hear about all the time.
What can we do about it?
Businesses often refuse to set aside any time for programmers to clean up code. They often have a hard time understanding how nonessential complexity crept in because, rightly so, they view it as something that should not have happened.
The only real cure for a codebase suffering from this debilitating and incremental condition is to take a vow to "Leave It in a Better State." In the same way that small detrimental changes coalesce into a big mess, small constructive changes converge to a much simpler system. It's helpful to realize that small improvements do not need to consume large amounts of time. Small improvements might include simply renaming a variable to a much clearer name, adding a small automated test, or extracting a method to improve readability and the possibility for future reuse.
Adopt "Leave It in a Better State" as a way of working and life will be much easier for you in the long term.
By Patrick Kua
This work is licensed under a Creative Commons Attribution 3