Aim for cost-effective code over clean code
Clean code is a joy to work with. It's easy to understand and change. Most developers would rather work with clean code than a code that resembles a plate of spaghetti.
So it stands to reason developers aim to write clean code. It's a matter of pride in one's work and empathy for the next developer who reads it.
But in this post, I want to zoom out past the goals of the engineering team and look at code through the lens of a business owner.
From the owner's perspective, the goal of the engineering team is to ship bug-free features at a high velocity for the lifetime of the business. It’s that simple.
Clean code often enables us to ship at a high velocity, but not always. It's a means to an end, not the end itself. The real object is to write cost-effective code.
What is cost-effective code?
The cost of code is developer time. It’s the present cost of time spent writing code plus the future cost of reading and changing it.
cost of code = time spent writing + future time spent reading + future time spent changing
A high future cost is technical debt, and it can be significant because code is often read and changed many more times than written.
Cost-effective code minimizes the total cost. It improves velocity by minimizing the developer time it takes to ship each feature.
Why cost-effective code?
As a developer, it’s easy to get lost in the weeds and start to view clean code as the ultimate goal. This can create a rift between the product and engineering teams.
At one of my first software jobs, the product manager would cringe every time I said I needed to spend time refactoring. I later learned, “I’m going to refactor this code” translated to him as, "I'm going to spend a bunch of engineering time moving code around without any noticeable improvement to show for it."
Rather than thinking of refactoring as a way to “clean up the code”, think of it as a way to “invest engineering time now to get even more engineering time back in the future”. Future savings will come in the form of reduced engineering time to read and change code.
Framing refactoring as an investment in engineering time helps the product team to understand the value of refactoring. Refactoring is no different from any other business investment.
Factories invest in machinery.
Recommended by LinkedIn
Airlines invest in planes.
Software companies invest in code quality.
Like other types of investments, some yield a high return, and others yield a low return. For refactoring, the return is calculated as:
Return on investment = (time saved - time spent) / time spent * 100%
Cost-effective vs. clean code
Cost-effective code gives you the highest return on your time. Clean code does not take into account return on investment.
That said, clean code is often cost-effective. Think about it like two overlapping circles of a Venn diagram. There is a lot of overlap between them, but understanding what is outside of the union will save you time.
Sometimes the most cost-effective code isn’t clean at all. A common example is writing a script that will be run once and then discarded. It doesn’t make sense to spend time refactoring because it won’t save any future engineering time in the future. It just needs to work.
The distinction between cost-effective and clean code is subtle, but it's important. It is a guiding principle you will use to make coding decisions every day.
Final thoughts
The main takeaway from this article is not to disregard clean code. My experience is that most engineering teams would benefit from a greater emphasis on clean coding practices - not less. Learning about refactoring patterns was one of the most beneficial things I've done as an engineer (ie. Refactoring Ruby Edition).
The main point of this article is to apply clean coding practices in a way that will give your team the greatest return on your precious time.
An engineer who understands both refactoring patterns and how to best apply them has a powerful skill set.
Actionable insights
Nice work! It would be an interesting time capsule to compare this with what we wrote in our App Academy Tunblr blogs back in 2015.
Don't know much about coding, but I do know that Mike documents everything. He says if you don't document, the code you wrote quickly will soon become a costly time waster. 😁