Be Rational—Delete That Code!

In a previous blog post, I brought up the concept of fighting the urge to rewrite code, and instead shift to refactoring code a step at a time until it takes on the features and characteristics that the business needs. Rewriting the code should only be considered a last ditch option. All that said, you will inevitably hit scenarios where you can delete whole swaths of your hard fought code:

• Refactoring – As you are refactoring code, you will inevitably hit the bottom of the refactoring stack and are now are able to delete whole chunks of code that are no longer needed.
• Dead End – While coding up a feature, you have found out that the track you have taken is a dead end. There is a need to wipe out all that code and start over on a different path.
• Fully Supported Third-Party Replacement – Whole chunks of your past work should be replaced by new frameworks and/or third party components.
• Long Gone Business Requirements – A feature that you poured years into is just no longer needed, and the expense of supporting it is adding up, so it needs to be removed. Nobody learned this lesson more than the Microsoft Internet Explorer team when they started work on the Edge browser (nee Project Spartan)

First of all: Congratulations! You work on a super nimble system which allowed you to refactor that code and get to a state where you can keep your business running while also being able to delete code and improve the future support story of the system. You have adhered to the awesome premise that all code should be written such that it can be deleted later.

You have already fought 99% of the battle to get to the final stage of code deletion.

You had the fortitude, confidence, foresight, and guts to be able to suggest that something you worked so hard on could and should be improved and even possibly replaced, for the betterment of the business and your team members. You had to fight your own irrational reactions to get to this awesome rational state.

Was it super difficult to start down the path of refactoring and/or replacement? As you were watching yourself and others refactor and shift all that hard-fought code into a new shape, was there a voice at the back of your head that you just had to suppress? It turns out you are not alone with that irrational voice, and it is a known condition.

Software Engineers get a double whammy of known psychological effects when it comes time for refactoring or replacement:

• The Endowment Effect – When we own something, we begin to value it more than other people do
• The Ikea Effect – The more work you put into something, the more ownership you start to feel for it

Please check out Chapter 7 of Predictably Irrational by Dan Ariely for more info. Predictably Irrational documents these effects as part of trying to understand the underlying mechanics of behavioral economics. I figure that software engineers sit at the confluence of economics, business, and technology. As such, many of the anecdotes and research that Mr. Ariely documents in Predictably Irrational seem even more apt for the software engineering community.

The Endowment Effect

Since 2010 you have been updating and maintaining a graphical drawing engine. Suddenly, a confluence of events occurs. Your business wants to augment the graphical drawing engine with 360-degree video, Virtual Reality integrations, and other high-end 3D features. You are the owner of the graphical drawing engine. You see it as needing to live, so you literally go to the Metal and start adding 3D features.

But it is 2016, and a new software engineer is talking about this Unity 3D engine. The suggestion from the other engineer is that you could keep your graphical drawing engine for 2D parts, then roll out the Unity 3D engine for all the new 3D features.

At this point, your irrationality kicks in, and you may not even realize it. You see your graphical drawing engine as having tremendous worth. Despite the fact that 3D is uber complex and doesn’t 100 percent fit-in with the 2D engine you have created, you want desperately to take on the 3D work into your 2D framework. You also think that other engineers share this viewpoint.

It is probably time to step back, take some time, and look at this whole thing from the perspective of a non-owner of the 2D engine. To a non-owner, there really is no need to rev up a custom 3D engine within the realm of the 2D engine. The Unity toolset is excellent, been in use by game makers for years, is affordable and stable, and easily integrates side by side with your 2D engine. It is hard, you are fighting a series of irrational behaviors, but you eventually throw in with the Unity 3D engine promoters.

Keep in mind: Your ownership attachment via the endowment effect was completely irrational. You may not even realize why you are thinking what you are thinking. This is why teams of good people are worth their weight in gold. They can help pull you out of your irrationality and on to other more rational paths by having the viewpoint of the non-owner.

You suffered through the irrational peculiarities of ownership (See Chapter 7 of Predictably Irrational):

• The more work you put into something, the more ownership you begin to feel for it (The “IKEA effect”)
• We can start to feel ownership even before we own something
• These ownership quirks apply to ideas as well as things…which is why we end up with ideologies that no longer seem rational.

The IKEA Effect

Now, imagine that you are a software engineer, you just spent a year on a whole bunch of code, created entire systems, it’s all stable, you are ready to ship.

Suddenly, you find a framework from Apple that does 110 percent of what your code does. You could literally delete all your code and replace it with a couple of references from the Apple framework and some recycled glue code from your year-long effort.

Your test time goes to almost zero, as Apple did it for you.

Your maintenance time goes to almost zero, as Apple has shipped and will maintain the framework for you.

What do you do? I put good money down that you ship and continue to maintain your code rather than use Apple’s almost identical, and superior, framework.

As Mr. Ariely points out, you are not just fighting a technical argument, you are put into an irrational state.

You may be suffering from The IKEA Effect:

… labor alone can be sufficient to induce greater liking for the fruits of one’s labor: Even constructing a standardized bureau, an arduous, solitary task, can lead people to overvalue their (often poorly constructed) creations. 

Delete the Code

Software engineering is decision making and trade-offs at the highest levels of human thinking; part art, part math, part rational, part economic, and as we may deny, part irrational.

To fight off this irrationality can be tremendously difficult. You may not even realize the depths of your irrationality, that is why it is called irrationality after all.

But there are things you can do when you recognize you may be heading into an irrational area:

• Trust your team – Ask for their opinion, trust their input.
• Remove yourself from the equation and look at the problem set from the perspective of the non-owner.