You’re a developer, you’ve just written a chunk of code that solves the problem you’ve been given, and you didn’t break any tests. Let’s check that code into the repository and check out the next problem to work on.

Or maybe we can take a moment, and do it better. Maybe taking a second (and third) look will result in higher-quality code.

Kent Beck, a software engineer famous enough to have his own Wikipedia page, is quoted as saying, “Make it work, make it right, make it fast.” A quick web search will show you several pages discussing this quote, some in great detail.

So, I’ll write another, and hopefully, I’ll provide two things to build on the existing literature. First, I’d like to put this concept in front of some programmers that might not have heard it, or if they have, haven’t taken it to heart.

Second, I’ll provide my own philosophy on the subject. Maybe it will different enough that you’ll get something new from it. I do have a slightly different take on it. Although I don’t want anyone to change the quote, maybe we can instead think of it as, “Solve the problem, make it maintainable, and make it perform.”

Solve the Problem

The first step in writing quality code is always to make it work. The code you’re writing is worthless no matter how fast it is or how pretty it is if it does not solve the problem, so I take this one step further: solve the problem.

You can follow every principle of object-oriented programming, behavior-driven development, or extreme programming. You can write the most awe-inspiring tests in test-driven development. All of that can be perfect, but if it doesn’t solve the problem, it’s bad code. Worse than that, you’ve wasted your time and your employer or client’s money.

The first and foremost thing you must do is fulfill the acceptance criteria. If your code does not do that, there is no reason to go on. Stop, go back, and solve the problem.

I find a lot of programmers don’t want to hear this, but writing plenty of tests should be a part of this first step. How many tests? To start, enough to ensure that the acceptance criteria are satisfied. After that, there should be enough tests that if during the next stages, or when we are fixing something six months or a year later, we will know if we break the code. Tests should document the function of your code and provide a guardrail for changing the code.

Make It Maintainable

Once the code and all the tests are working, we have an opportunity to step back and objectively look at the code. We can decide what “make it right” means to us here. For me, one thing very high on the list is maintainability. Make it maintainable.

This could be as easy as making sure you run a code formatter (also called a beautifier). Truthfully, this is something you can and probably should be doing throughout the coding process. If nothing else, you might find an out-of-place curly brace. But on this next pass-through, make sure the code is following the format your team has settled on. If your team doesn’t have one, and I do suggest to teams do this, the standard one in your IDE (integrated development environment) will suffice.

This step can sometimes include a major refactoring. Perhaps you’ve coded everything into one long, multi-page method. It might make sense to break that up into different methods and give each method its own functionality (and possibly its own test). It’s possible you might even be able to reuse that method and get rid of duplicate code. NetBeans, the IDE that has been my go-to for quite a while now, has a function under refactor that will take highlighted code, make a method out of it, and then replace it with a call to the new method. I frankly love this utility.

For heavy refactoring at this point, I often step away from the IDE and use ViM, arguably one of the most powerful programming editors built. I do this for two reasons. First, I don’t have to worry about the IDE trying to compile the file as I’m moving stuff around and distracting me by telling me it won’t build.

Second, I’ve used ViM for so long (since the mid-90s) that I can be very precise with what I’m doing, especially when it comes to cut-and-paste operations. I can never be as precise with a mouse. Also, the ability to script functions, assign functions to keystrokes, or repeat operations is extremely helpful when refactoring.

And in case someone asks… Yes, I am aware you can get plugins for most IDEs that give you Vi(M) keybindings, and yes, I use them.

Make It Perform

One thing about the “make it fast” stage that I would caution against is using it to undo the work you’ve done to write quality code in the previous stage. For instance, you might be able to speed up your code by doing away with multiple methods and having one long method, but I don’t think the minor speed gain is worth the maintainability setback. So, I prefer to call this stage “make it perform” instead.

Context of course applies here. I have worked on projects where speed was the overriding factor in everything. One thing that was true on those projects, anyone who was not the original author of that code hated maintaining it, and some of the original authors did, too.
Also, in my opinion, the speed of the code itself is not the only important factor. I would say that optimizing the code for the environment is far more important.

During this stage, I would begin to look at areas that might impact the long-term performance of the application. Are you creating unnecessary objects that will affect garbage collection? Maybe you created a variable and instantiated it because when you first wrote it, you felt you needed an object there. But while coding it, you overwrote that object with another object and never actually used the original. The code works and does not generate any bugs, but you now have an object that must be cleaned up that was never actually used.

Take some time to clean up such code in the context of where you are running it. This is essential in achieving high-quality code!

Write, Rewrite, and Rewrite Again

One of my goals in life is to become a professional author. So, I’ve done some reading in that area. Anyone who spends any time writing, even just blogs like this one, knows that once you get the idea down, you must go back and proofread your work to fix the errors that are there.

You will find simple errors, such as using “there” for “their,” and far more complex errors that prevent you from getting your idea across. Programming and writing have this in common!

I recently ran across the idea of “write, rewrite, and rewrite again.” When you think about it, this expresses the same concept as “make it work, make it right, and make it fast.”

First, you have to get your ideas down, make it work, or solve the problem. Then, you proofread your work and fix the errors, make it right, or make it maintainable. Finally, you go back through and make sure it succinctly conveys your point, make it fast, or make it perform.

Conclusion

Don’t be afraid to go back and take a second or even third look at your code, especially if you have adequate tests to back you up. Don’t spend forever trying to get every line perfect, but do spend a bit of time making it better. Trust me, it’s worth the time. You will be thankful to have better-performing, easier-to-maintain, high-quality code.

Hats off to Mr. Beck. “Make it work, make it right, make it fast” is a good philosophy. For me, those translate into, “Solve the problem, make it maintainable, make it perform.” I challenge you to think about what those three steps mean to your process of writing quality code.

Let me know how you apply this concept in the comments below, and as always, if you enjoyed this post, check out the Keyhole Dev Blog for many, many more.