Write code that is easy to delete

Preamble

The precepts that I want to introduce and and discuss are:

Write code.

Write code that is easy to delete.

In this post I explain my reasons for endorsing this adage, and why I think it can be generally useful.

Introduction

Like most responsible software developers, I want to code well. Authors of the guidelines, books and blogs that address this goal have a willing audience with whom to share their ideas and practices. And, in most cases, there is huge benefit to be gained from familiarising oneself with established best-practice and trying to stick to it.

However, sometimes the more I read on these subjects the more ignorant I feel and the more inadequate my efforts appear. My quest to scale the lofty peaks of self-improvement quickly descends into the abyss of self-flagellation. Too dramatic? But with so much advice out there, it can feel very difficult to tick all the boxes, whilst also actually getting things done.

In these cases I find it helpful to remind myself of the adage above. The first thing we should do is write some code. Next let's try to make sure that the code we write is easy to delete.

Write code

When faced with a problem which we intend to solve using software, it is important that we carefully dissect the problem and the potential solutions to it. This is what we have been taught to do as developers or engineers. For example, we should:

• Weigh up the pros and cons of different approaches
• Consider different technologies that could be leveraged
• Design the solution to be flexible to evolving needs
• Plan the implentation
• Design tests which will prove the efficacy of the solution
• …

There are so many things that should be going on here, and some of it implies that you already have a pretty good picture of what the solution is going to look like. Personally, there can be a real risk of decision paralysis, whereby the volume of considerations we are trying to juggle actually prevents us from getting anything done.

When I find myself slipping into this trap I remember the first precept:

Write code.

As a software developer, the physical act of writing the code is often second nature. As you code, a level of muscle-memory is invoked and your brain can work through the problem as the code evolves. When you have something written, it may fall completely short of where you are hoping to get to. It may only address a tiny element of the problem you are faced with. But it gives you a starting point from which to evolve and build your ideas, and this is important. You may end up refactoring this early code extensively, you may delete it entirely. That's fine. What is important is that every journey starts with a single step, and for a software developer that first step usually means writing some code, any code.

Let me be clear, I am not advocating heedlessly rushing into a coding the solution without taking the time to properly consider the problem at hand, and the potential solutions. And I am not dismisisng the value of proper planning and design of a software system. Rather I am saying that, the act of coding can help crystallise your understanding of a problem. And certainly, if/when you reach the point where you feel overwhelmed with decisions, or where elements of the final solution are not clear, then the act of starting to code the solution can really help to clarify your thinking on the matter.

As mentioned, the code you write here will probably not be your final solution, you may throw it away entirely.

Write code that's easy to delete

If you are a software developer and you think that all of the code you are writing is essential to the future of your business, your client or the world in general, I think you are mistaken.

Why? Well, the statistics would seem to support this view. As developers, we're all over the place, across all industries in innumerable companies. This article attempts to make some ball-park estimates: 6 million developers across the globe churning out ~93 billion lines of code per year. These are mind-bending numbers, but the estimates seem reasonable.

With so many developers producing so much code it is inconceivable that every piece of software being developed has long-term value. Indeed, it would seem that only of a small fraction of what is produced actually continues to be useful into the future. I am sure most developers can validate this anecdotally from their own experiences: That client project you worked on, where the the client went bust soon after. That code is dead. The projects you slaved on for months which ended up being canned after a short period. Again, dead code. Or, even better, the project you worked on for months which got canned before it ever saw the light of day.

In all of these cases, the code that was written is dead and gone, but usually it is no reflection on the quality of the code or the quality/experience of the developer responsible for writing the code. Perhaps it was poorly implemented, or perhaps it was a poor business idea, perhaps it was poorly marketed, perhaps it was poorly supported, perhaps it was bad timing or perhaps it was just bad luck. Who knows? The point is this: most of the code you write is not going to last for a long time. So when you are contributing to a large project, bear this in mind and do everyone a favour (including your future self): make your code easy to delete.

In order for the project to be successful, the lifespan of the project as a whole will usually need to be longer than the lifespan of the code you are writing.

And does this only pertain to those of us who work on large, established code bases. If you are working on a green-field project is the situation different? In my opinion, no, the same principles apply: a successful project will outlive much of the code you write, so make sure your code is easy to delete.

Not such a revolutionary idea

So whilst I am pitching this idea of:

Write code that's easy to delete

as being something novel, it is really covered by the existing and established principles of software development.

How do we write code that is easy to delete? Well if you practice encapsulation, if you adhere to the single-responsibility principle, if you use dependency inversion … you will be in a good place. Generally, if you try to ensure loose coupling between the code you are writing and the existing code, then you will likely have code that is easy to delete.

So it would seem that my advice is: "Follow all the existing good design principles", which sounds like a bit of a cop out. Sorry! But for me, personally, the benefit of striving to write code that is easy to delete provides a goal which is easier to internalise and focus on.

Summary

I have introduced two simple precepts that I often refer back to when trying to solve a problem or contribute to a project.

Write code: When design decisions and questions threaten to paralyse your ability to make progress, the best thing you can do is write some code.

Write code that is easy to delete: It is highly likely that the code you write will have a shelf life that is shorter than the project itself. If you strive to make your code easy to delete you will be doing everyone a favour and by adopting this principle you will, by necessity, satisfy many established principles of good design.

Of course, when it comes to maintaining mature applications, removing an existing feature is not as simple as deleting the code that supports that feature, but that is a post for another day.