Don’t Let Your Developers Refactor

This article is intended for managers of software development teams.  If you are a developer and you are reading this please don’t hate me.  I feel like a magician that’s breaking the magician’s code and revealing secrets to the uninitiated.  I plan on writing an article for developers that explain how to communicate and manage your manager’s expectations (spoiler alert: you incorporate refactoring as part of feature requests) but until then you have been warned…

Let me start by saying that while I’m in a management role, my day-to-day involves a lot of coding and I have spent my entire career in largely development roles.  Let me further say that I love well-designed code and I love refactoring. Here is an all to common occurrence that happens in development:

That said, developers have a propensity to call for refactoring or worse yet rewrites!  I would know, I’ve done it a lot.  But don’t let a call for refactoring raise a red flag that you have a bad developer.  On the contrary, a developer that wants to refactor is one that cares about the code and you want developers that care.

Developers will give many good reasons why they should refactor code and try to convince you to give them the time they want.  However, calls for refactoring are usually symptoms of deeper problems.  And allowing refactoring without solving the deeper problems is putting the cart before the horse.  Instead of halting development to refactor, help them avoid the need for refactoring in the first place.

Here are some of the deeper problems that cause the need for refactoring:

Technical Debt

Technical debt is a concept in software development that arises from choosing the quick fix over well-designed code.  It comes from many sources but the number one blame is usually business pressure.  This is probably the problem that you as a manager have the greatest impact.  

How many times have you had a meeting with stakeholders where you decide which features you need and by when without consulting the development team first?  It’s good to at least get a ballpark figure for features before prioritizing them.  A feature that you think should take a week but would really take a month may be a lower priority than a different feature that would take a week.

The more you force your developers to take the short cut the more technical debt you incur and the longer it goes unfixed the more interest you have to pay to fix it.  The interest you pay comes in the form of slower feature release, more bugs, and unhappy developers that may start jumping ship.

Poor Communication

To be a good developer you have to be able to think analytically, concentrate deeply on one thing, and understand many things intricately. That is why most naturally good developers are introverts.  This isn’t a bad thing but since most managers are extroverts you will have to take special care to try and understand what’s going on in the mind of your developers.

I have worked at many companies where “teamwork” consists of dividing tasks in a way that each developer works on a different part of the system without any interaction with other developers.  This helps prevent developers from blocking each other and seems like a really efficient way to get things done but it creates several problems.

Often you will get a developer that makes a bad coding decision whether from a lack of experience or lack of understanding.  Sometimes when two developers don’t communicate they create duplicate code.  Other times your developers will specialize in certain pieces of the code and not understand how the other pieces work or how they work together.

There are a few things you can do mitigate these problems. First, you can make sure your developers use “pull requests.” This means that before any code is added to the main code it has to be approved by another developer.  Second, you can institute “pair programming” sessions.  Pair programming is where you have two developers sitting at one desk with one monitor and one keyboard/mouse.  One developer does the typing while the other developer analyzes the code and they switch roles frequently. It may seem like this means you will only get half as many features but your code will be twice as clean. And third, you can assign an “architect” that makes all of the coding design decisions but you have to be careful that the architect doesn’t make bad decisions and gets along well with the developers.

Chasing the Silver Bullet/Shiny New Tool

Especially in JavaScript and Front-end Development there are constantly new tools being released.  It’s such a problem there’s even a name for it “JavaScript Fatigue.” The following XKCD comic that while speaking of standards could easily apply to JavaScript tools:

When a new tool gets released that’s supposed to solve all their problems or when developers have friends at other companies that have started using a new tool it’s tempting to switch and try it out.  The biggest problem is that tool preference is different for each developer so switching tools is a matter of preference and not of efficiency.

Many of us developers have a desire to be hip and cool and follow the latest coding trends and use the latest and greatest tools but that’s a nasty trap you can fall in.  You may be weeks into developing with a new tool and it turns out you don’t actually like the tool or people have already stopped using that tool in favor of a newer shinier tool.

I worked at a large company where we were going to start a brand new project from scratch and one of our developers convinced us that we should use Ember.js. The problem was it was still in beta and while it was fun to use they kept releasing breaking changes that would force us to go back and change our code.

I worked at another company where the code was written in the PHP framework Zend 1 even though Zend 2 had been out for a year.  The problem was that Zend 2 is incompatible with Zend 1 so we had to do a full rewrite to use Zend 2.  It’s strange how code you’ve been working on for a long time that works well suddenly becomes old or bad when new software is released.  What worked yesterday, works today.  And full rewrites are never the answer.

Lack of Style Guides

If your developers aren’t using a style guide you need to get them to.  A style guide determines what the code should look like. For example, if they are going to use snake_case or CamelCase.  It really doesn’t matter which they use as long as they are all consistent.  There are automatic tools out there that can be used to test code before it’s committed to make sure it follows the style guide.

Lack of Tests

Without tests there’s no way to maintain quality in code.  Every change that a developer makes may introduce a bug.  If you let a developer spend a week doing a refactor and your code doesn’t have testing all that’s going to happen is you’ll be a week behind on your roadmap and your code will have more bugs.

You don’t need a QA team to do testing.  Every language I’ve worked in has tools for automated unit testing and automated integration testing.  Don’t let your developers do any refactor if there aren’t any tests.

Lack of Knowledge

Computers have changed a lot over the years and so have the tools we used to write code.  But when you look at well-designed code, software design patterns haven’t changed a whole lot in the past 20 years.  A lot of developers are learning good coding through trial and error but there are plenty of resources out there that can accelerate their learning.

Sending your developers to coding conferences not only increases their skill but will increase their job satisfaction.  I would also recommend implementing quarterly book reading where all of the developers read the same book and every Friday for lunch they discuss what they’ve read.  Here are some books I recommend:


Instead of carving out time where no new features are being developed so your developers can refactor, work to solve the underlying problems that cause the need for refactoring in the first place.

With all of that being said, refactoring is essential to having good code.  And while you can mitigate a lot of refactoring by following best practices and doing everything you can do avoid having poor code written in the first place it is inevitable. As projects grow and new features are added, code will need to be refactored. But instead of bringing development to a halt it needs to be a natural part of the development cycle.

To review, here are the things you can do to avoid refactoring:

  1. Avoid unrealistic deadlines.  Make sure all roadmap and timeline decisions are made with developer feedback.
  2. Implement pull requests.  Don’t let any developer commit any code without at least one other developer’s approval.
  3. Implement pair programming.  Let developers work together to achieve better software the first time.
  4. Stick with tried and true tools.  Don’t let your developers try every new tool.
  5. Rewrites are never rarely the answer.  That’s what killed Netscape Navigator.  The answer is incremental migrations and changes.
  6. Implement style guides.  Make sure your developers are consistent and agree on a standard.
  7. Implement testing.  Allow time for your developers to write unit and integration tests.
  8. Implement quarterly book reading.  Buy all of your developers one of the books I’ve listed and reward them for reading it.

Do you have any other suggestions that have worked for your company?  Please share in the comments!


No account yet? Register

Published by Chris London

A serial entrepreneur, Chris is currently co-founder and CTO of tech start-up Cinch. Cinch is an automated marketing platform designed to share the right message at the right time with your customers.

Leave a comment

Your email address will not be published. Required fields are marked *