Getting our code to work is great (and obviously necessary). But as professionals, we know that getting code to “work” is only 10% of the job. It also needs to work well.
This is why we can't write Dirty Components, but instead need to write Clean Components.
A Clean Component has a fairly simple definition:
A Clean Component does not hold you back from being productive over the long term.
Or to put it another way: you don’t curse out your previous self when you return to the code you wrote a year ago.
This is exceedingly important, because while a new component might take only a few hours of your time to initially create, its lifespan is likely measured in hundreds of hours of work across dozens of software developers.
Instead of optimizing for the initial few hours, we need to be optimizing for the long-tail future hours of work.
This is how we increase our productivity in the long run.
In this article we’ll take a look at:
First, some more detail on what a Clean Component is.
What this actually means for a Clean Component are two main ideas:
These ideas are intertwined and connected, of course, as many important ideas in software development are. A component that is easy to understand is usually easy to modify. And a component that is easy to modify must be easy to understand.
Let me quickly clarify these before moving on:
When I say “easy to understand”, I mean that it’s easy for a human to understand the code.
This means that the code is organized in a logical, consistent way, and the component makes it very clear what it’s purpose is and what it does. This also means it is clear what the component does not do.
A simple test for this would be: if someone who has spent time in your codebase came upon this component for the first time, would they be able to easily understand what’s going on?
Would they know what they can use this component for?
Would they know the responsibilities of this component?
When I say, “easy to modify”, I mean that it’s easy to make changes that improve the code.
This naturally flows from being easy to understand, but it’s actually the point of this whole thing called software development. We aren’t here to understand code, we’re here to write it and do useful things with it.
So it should be easy to add a new feature without introducing bugs. It should also be easy to find existing bugs, and then easy to fix them.
I would even go so far as to say that because this Clean Component is easy to understand, it should have less bugs in the first place. Errors in code usually come from errors in understanding, which is precisely why being able to understand the code is so important.
Testing, documentation, and all of the other engineering best practices do help with making code easier to modify. But they fall outside of the scope of the component itself.
So let me explain why the idea of Clean Components is so powerful.
If your components can be Clean, they will help you to be productive over the long term, not just productive “now”. Not the kind of fake productivity where you get the feature to “work”, ship it, and then move on despite all of the festering garbage you’ve left behind.
No, I mean productive in the future.
You want to be productive in the future, so you aren’t completely screwed when you (or someone else entirely!) have to return to your code in six months, or in a year, or even 4 years down the road.
The cost of that dirty code you leave behind only grows more and more over time:
Returning to code in four years or more seems hard to imagine if you are a new developer or work at a startup. But every successful startup eventually becomes a company with very old code kicking around.
Is the code you’re writing today going to be easy to work with four years from now?
If you want to be productive in the future, you need to make sure you’re focusing on the right things.
Everyone loves working on new components. You get to play with a blank, untouched canvas, and development is so fast! There’s less tech debt and less friction to slow you down.
Existing code, however, has tons of friction. You have to deal with all of the poor decisions, neglected code, quick hacks, and Dirty Components that have been left behind by others (possibly even yourself in the past).
This is why we call it “legacy” code, and then procrastinate and read articles like this one so we don’t have to touch it.
But this is where things get weird.
Because it seems as though our industry mostly focuses on how to write new code, not how to modify existing code.
When we talk about become better developers, it’s (almost) always about writing new code faster, not about refactoring old code to be better.
Tutorials are written about building a new feature, adding in a cool gadget, or how to adopt or migrate to the latest tech. Articles aren’t often written about how to make the code you already have better.
I find this extremely strange.
Because for most of us, we spend most of our time modifying existing code, not writing new code from scratch.
So we should spend our energy focusing on how to make our code easy to modify in the future. Long term productivity is what we should be optimizing for, not the short term productivity of getting the code to “work”.
We should be spending our time thinking about and making sure that our code will evolve well over time. We need to think about how developers will interact with the code in the future.
Will it be easy to add new features?
Will it be easy to make this more generic? Less generic?
What about tests? Maybe we can’t write all the tests that we want for it right now, but we can at least make it easy to add them later when we do have the time.
It doesn’t matter if you can smash out new code really fast when it’s only a small part of your job.
That’s what Clean Components are all about.
That’s why writing Clean Components is so important.
If most of the time you’re modifying existing code, you want that process to be as easy as possible, right? That’s exactly why Clean Components exist. To help you minimize that drag on your long term productivity over time.
If we can make it painless — at least as painless as possible — to modify existing code, that’s a massive win for us!
The cleaner your components, the more productive you’ll be in the long term, and the better your code will be.