The Fine Art of Deleting Code

Don’t be too proud of this technological terror you’ve constructed.

Serenity by Lazarus (CC-BY). Part of the album Goblins.

“The thing about code is, every line you write is another ball and chain around your ankle.” — Joe Hicklin

We’ve all been there. We did it! We got the code to work! The page looks good, the server is fast, the API brilliant, and the results accurate. We’re done, right? No.

Now comes the next, and some would say the hardest, part: revising. And that means the bugaboo of Deleting Code.

Writing Is Revising

As a writer, I’m overly familiar with this process. Even more than code, writing a compelling story is a process of writing, revising, reading what’s there, writing more, revising more, bouncing it off test readers (“code reviewers”, for you programmers out there), doubting yourself as an author and the whole process of authoring, and revising some more.

Programming is much the same way, except that in most environments, the review process gets short-changed; there are no ‘editors’, let alone the division of line-editor/development editor/etc. one sometimes finds in publishing. It’s still important. The difference is, you have to make time for it.

When you’ve finally gotten the code working, depending on your coding style and time pressures, you likely have a lot of stuff that looks like this:

function fetchData({ username: string, itemsToGet: array[] }) {
  //  for (const i in itemsToGet) {
  itemsToGet.map(i => server.get(username, i).then(res => {
    if (i !== undefined) {  // We are getting junk data, filter it out for now
      // console.log("Got response!: ", res);
      handleResponse(res);
    }));
  }
  //  }
}

This can probably be simplified, and definitely can be cleaned up. Why is all that commented code still in there? Why is this loop half in functional style (map, then) and half in iteration style (for _ in _ , if (_))?

The problem is that this code works. So we’re afraid to touch it. At least, we think it works.

The other problem is that this code could be replaced by something vastly simpler and easier to understand. And that difficulty will come back to bite you later, one way or another.

Deleting With Confidence

“Should (noun): Won’t.” — Jeremy Hughes (and anon)

You know what you should do. The whole thing should be simplified. You should move to one paradigm. Hell, now that you look at it, the whole thing is probably not worth a function; it’s just itemsToGet.map(i => server.get(username, i)).then(handleResponse); which also makes it clear that you haven’t handled a catch clause.

But it’s working! so you don’t want to touch it!

We now pause for station identification. If you’re enjoying reading this or any article here, Clap for it, so we writers know. It does not earn me any money, it just gives me warm fuzzies.

“If code isn’t covered by testing, it’s not working, it’s working by accident.” — John Micco

Testing is one way to give yourself confidence. I’m not going to extol the virtues of testing here; if you are giving development priority to include testing in your workflow, take advantage of that, and if not, agitate for it.

Another way to gain confidence in making changes is version control; git is your friend (if not your fully-known friend). Tag that branch before you explore! Did you know you can tag literally any commit, and that it’s a fabulous way to communicate with future-you? It’s even lighter-weight than throwing a new branch, which can be intimidating to think about; all you’re doing is throwing down a “Save Point” to restore to if/when the changes don’t work out.

Knowing, git

Even a test plan — rather than automated testing — can give you the confidence to make changes. “I click on this, this shows up, it’s not empty, it has this data.” For some systems — I’m looking at you, GUIs — it’s sometimes easier to be the test runner than to write proper unit tests, and honestly, sometimes it’s the right choice (usually for small or rarely-used corners of the system — or when you haven’t figured out what the right behavior is yet).

Kondo That Crap

I have no idea who Marie Kondo is, but you do. I get the impression she tells people whose lives are full of extra stuff that they should instead make sure the garbage dumps are full of extra stuff, which is a sentiment I have mixed feelings about. (I hear ya. My house is full of stuff. But it’s my stuff.)

The nice thing about throwing away code is that it’s 100% environmentally friendly; it’s 100% reversible, though the re-integration may require extra work; and it’s 100% gone when you do. Well, not quite 100%; old code leaves marks on a codebase, the way a bookshelf leaves marks on a carpet after years of sitting in a place. But a mild refactoring can usually get rid of those.

So invest in the refactor. I believe in you! You can do the thing! You’ll be happier (and more productive) afterward, and you can fill the new space in your brain with brand-new clutter.