Advantages of Clean Code
A high-level introduction
One of the things I’ve seen occasionally in industry is the attitude that “clean code is a waste of time” or that “shipping code is more valuable than clean code.” In an isolated sense this is true: We are paid to ship and the cleanest code in the world doesn’t matter if you can’t get the project out the door in a reasonable (context dependent) time frame.
This attitude gives us a scale, where on the one hand we have “quick and dirty” and on the other hand we have an “ivory tower architecture.” To me, this is a false dichotomy. I’ve seen “quick fixes” that were quite cleanly done, with well-written tests, descriptive variable names, and a reasonable level of abstraction. I’ve also seen huge, sprawlingly, and complex implementations that were thought out end-to-end and are neither tested nor intelligible to the person who wrote them.
Suffice it to say, it should be obvious that “clean code” shouldn’t mean “overengineered code.” Perhaps to be clear about this we could talk in terms of cleaner code, rather than simply “clean code”: Recognizing that we are looking for a process of continual improvement and a gradated curve, rather than a single uniform and well defined ideal.
So what are the benefits of clean(er) code?
Easier to Test
Messy, complex code is difficult to test. It isn’t just difficult to unit test, but it is hard to do any sort of automated testing if the underlying code is messy. Sure, it can theoretically be done, but cleaner code is usually easier to test and–more to the point–easier to diagnose when something does break.
When a test fails–be it automated or manual–it is almost always going to be easier to find the source of the failure of the call path doesn’t pass into a mass of spaghetti at some point.
Lower Maintenance Burden
The vast majority of the cost of software is not in the initial construction: it is in the maintenance, with most of that maintenance involving activities other than directly fixing bugs.
Maintenance is expensive and, worse, it has a tendency to compound. Every minute required to orient yourself to a code base is a minute that you aren’t designing or implementing your solution. If you can lower the maintenance burden, even by a little bit, that has a compounding effect on your ability to actually ship code.
Lower Communication via Osmosis
Clean code is easier to read, modify, and refactor for people other than the original programmer. Sure, I can read my code, but can a junior engineer? Can an experienced programmer who just started here? Can they both make changes in that code base with some confidence that their changes are correct?
Frequently in messy code it requires a domain expert to even understand why the code, in isolation, works. In clean code you may not see the whole picture, but it should be obvious what the problems are in the microcosm, and if you break something you should have at least some confidence that it will be caught before it hits production.
Feature Isolation
If feature X is changed, what is the probability that feature Y will also be manifesting difficulties? Robert C. Martin points out that:
Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. Every addition or modification to the system requires that the tangles, twists, and knots be “understood” so that more tangles, twists, and knots can be added.
If the code is clean, then it significantly easier to determine whether a change is “trivial” and whether a change to support X should have an impact in some remote part of the system. Changing the system is much easier, because the components interact in well-defined ways.
Bugs Are Obvious
Clean code is almost always simpler code, code in which the presence of bugs is more obvious. This allows the developer to get better feedback during code review, since mistakes of reasoning will not be obscured by unnecessary complexity.
Happiness
I have no data on this, but call it a hunch: Developers working in a clean code base are going to enjoy it much more than developers working in a messy code base.
If “morale is a multiplier for velocity” then it implies that code should be written so as to minimize the amount of pain that the maintainers feel down the road.
Conclusions
All of this should be relatively noncontroversial. What, exactly, constitutes clean code may be a little more difficult, but it should be clear that, whatever it is, it is worth striving for and talking about within an organization. Even if it is not attainable today, the conversation is well worth having.
Later on I’ll talk more about what is needed for code to be clean and about how to get clean code when you are starting with a mess, but for right now I wanted to start with the very basics: Why clean code is good for your ability to ship and why, in the usual case, clean code doesn’t slow down your organization.
