We need to refactor again!

CEOs and Product Owners have all heard this refrain!

It causes stress. It adds time to the roadmap and stresses out teams. This article is a quick exploration of this character trait of developers.

We do not do this to annoy. And we are not trying to slow down a project.

To understand why this pattern is so common, it can help to unpack the mind of a developer. While code is complex and sophisticated, the reason why developers default to this approach is simple, if you understand the mindset of your tech team.

It’s more fun to start fresh

Most developers when faced with changing requirements will, at some point, mentally throw up their hands and option for a ground-up rebuild. i.e. a refractor.

Technology Back Pressure?

There are three major factors putting pressure on developers. New cloud solutions & approaches, new vendors and products and new code libraries.

Example. In 2012 I attended the second Backbone.js conference in Boston. Backbone JS was a short-lived, but wonderful library that provides views, models and controllers for the new patterns coming up with single-page applications (aka SPAs). This library’s lifespan was short-lived. Measured in months. The evolution of libraries and frameworks like Angular, Vue and React supplanted Backbone.js within eighteen months.

Sadly, there was no Backbone.js Conf the next year.

At the time we all were using Underscore.js, a library for array and object collections work that had grown out of the New York Times Data visualization team and their grants from the Knight Foundation. During the conference, a presenter launched a new library called LoDash (a play on the keyboard underscore character). This new library took the patterns of Underscore.js and added browser hacks that added dramatic speed improvements. It was lauded as a drop-in replacement.

I watched as developers learned about the drop in replacement value of this new library, opened their laptops, and hot-swapped the library. At a conference, during a presentation! It was amazing to see how much developers love the new shiny and sexy library.

Code Complexity

One of the unstated reasons that developers recommend replacement is code complexity. It takes a lot of time to learn a new codebase, internalize the patterns and then get comfortable enough to start making changes.

We are not lazy, we just always think starting fresh is easier, better, or faster. We do not want to own someone else’s code. We do not (really) think they did it well. Developers love to curb-stomp the views developers work. My code is always better. :)

How to push back?

There is no simple solution. Being forewarned is the first step. Refactors come with their own unique set of risks. One approach is to request the developer to provide a detailed assessment of the reasons why the current solutions are not viable. Detailed, is not a verbal summary. Forcing a developer to take the time to outline specifics, can sometimes break the spell.