One of the most exciting things that happens when you learn to code is getting something to work.
That first time you follow the steps, put the pieces together, and voila: you made the code do the thing you saw in your mind.
It's so addictive that it's easy to get sucked into an idea for hours on end, time whizzing by, with your focus on nothing other than the task at hand.
As you get comfortable with this, you slowly transition from novice to intermediate. You not only know how to make it work, you know how to do it again and again. This is the point where you can feel seriously empowered. You have an idea for something and you actually know how to build it.
This is a real wow moment. It's also where things can start to go off the rails a bit.
Making it Work, Making it Right, Making it Fast
A quote that I came across that captures this idea well with just a few words:
Make it Work. Make it Right. Make it Fast.
— Kent Beck
Kent Beck is a programmer who's been around for awhile. He's the inventor of the Extreme Programming methodology. While the methodology encompasses a lot of different ideas and techniques, its core focus is on improving software quality and a team's ability to respond to changing customer requirements.
When it comes to building a great software product, this quote by Kent is everything. If we unpack it, what it's getting at is the importance of refactoring.
What is Refactoring?
Let's use the example of developing a cake recipe from scratch. Assuming you've never made a cake before, the first time you do it there's a lot of guessing involved. You pick out the ingredients that seem appropriate in the correct amounts, mix them together in the order that seems best, and bake the cake until it looks about right. If it tastes good? Awesome.
Code can be thought of in the same way. If we've never built something before, it's inevitable that we'll struggle to think of the best way to write the code for it. We can get it to work, sure—just like we can make an edible cake—but it may not be the best.
How would we improve our cake? We'd take note of what tasted good before, tweak our ingredients list, hone in our proportions, and maybe bake it a bit longer.
This is refactoring. We're trying to take something that already works and make it better.
Why? Well, a simple question is "who doesn't want to eat a better cake?"
Granted, code may be a harder sell since you can't eat it, but the point isn't lost. If our code is better, by extension, our product is better. If our product is better, it's more likely that customers will stick around because they're happy, and it's more likely that they'll tell others about it, too.
Nobody ever asks "where can I get a really crappy cake," do they?
Making it Work vs. Making it Right
Where refactoring comes in is bridging that gap between getting an idea to work and making it right. "Right" is fairly subjective. Typically, I classify code as being "right" when it's organized. It has a noticeable structure. It's easy to read. You can follow the logic from start to finish and understand it with ease. Things are named properly.
I can go on. The point is that there's a noticeable amount of care and consideration that's been put into writing the code. It's not just slapped together.
Making it Right vs. Making it Fast
Refactoring can go further, though. Just because your code is well written doesn't mean that it performs well. Beautiful, well-organized code can still be beautiful, well-organized, and slow. Slow, here, meaning the perceived time it takes for a feature to "do its thing" from the customer or user's perspective.
Making code faster requires spending time thinking about bottlenecks: points in the code that are noticeably slower than others. Finding these takes a bit of sleuthing. You have to first observe slowness overall (for example, uploading a photo takes a really long time) and then start to break down the parts.
Taking the example of uploading a photo, there may be three distinct parts involved:
- Loading the photo into memory on the client (browser).
- Transferring the photo's data from the client (browser) to the server.
- Transferring the photo's data from the server to a third-party storage service or CDN like Amazon S3.
At any of these points, there could be a slow down. Again, the code performing the upload may be beautiful. That wouldn't eliminate the fact that the technique used for transferring the photo data from the client to the server is inefficient; the feature will still be experienced as "slow" by users.
Making the Time to Refactor
Talking about refactoring is one thing, but how do you actually find the time to do it? To be fair, refactoring can be time consuming. It can require a lot of thinking and deliberation about the best path forward. As long as you're patient, this isn't too bad from the developer side of things.
On the non-technical side, however, refactoring can seem absolutely useless. It can feel like a massive waste of time. If you're in a job or working with a client, the way around this is to communicate the why. In addition to the above, it could be explained like this:
- "This will ensure that customers have as few issues as possible (because we'll take the time to consider edge cases) and we can reduce support requests."
- "This will make us more money because it will speed up the time moving from the product view to the cart view."
- "This will allow us to onboard customers more quickly ensuring they get access to the product in less time."
The feature(s) you're looking to refactor don't matter here. The point is to tie it back to business value. When it comes to refactoring, it's very rare that there isn't some level of business value that will come from it. If you can take the time to find out what that is, getting time to do a refactor will be much easier.
Make the Time, Develop the Discipline
Refactoring doesn't happen on its own. Ultimately, it's up to you the developer to make it happen. You have to make the time, communicate to others, and get the job done.
The saving grace is that if you develop a discipline around refactoring, all of the time that you waste chasing down bugs later will vanish. It's a guaranteed byproduct of taking the time to make things right and make them fast from the outset.
If you don't cut corners and invest just a little bit more into making sure your code is the best it can be, you—and your customers—will be far happier in the long run.