When to refactor, and when to slash and burn it

I’ve said it many times before, but as programmers we tend to spendthe bulk of our time working with broken software, and we try to endeavor to make it less broken. When it’s not broken enough to keep people from using it on a day-to-day basis, you release your software. Some places do this better than others, and at my day job we’re really good at it. We are very dilligent about our software releases, we have tons of unit tests, system test automation, a nightly test “dashboard” that shows us how well our tests passed, and so forth.

But even though we rock at our tests, regardless, there are things that we would like to have work better than they do now. That’s what differentiates players in the marketplace. You can have a product that works, but if it doesn’t work as well as your competitors, or it doesn’t solve problems your customers have, then you might as well not be in the game at all.

When to refactor?

So when do you refactor your code? When do you decide that what you have could be improved and you should change the way it functions? Usually this happens as a customer suggestion, request, or demand. Product management may decide that a feature should be added, or an existing feature should be improved. That’s when we programmers dive in, and change what’s there while trying not to break it. Hopefully, in the process, you’ll come out the other side with better test coverage, and will have or improved the code around the areas you were working.

Sometimes this isn’t enough though. What if fundamental design decisions about the section of code you’re working on isn’t up to the task of the refactor? Or perhaps the code has just outlived its usefulness, and needs to be thrown away with the bath water?

When to throw it all away?

Inevitably we just need to set fire to the whole thing and write something new in its place. Slash & burn. This is the decision I’m faced with now. We have a feature that hardly any of our customers use. Some people say it’s because other sections of our product work so well, that this troubleshooting interface just isn’t all that necessary after our customers gain confidence in how well our product works.

I personally think people don’t use it because, well, it’s slow and ugly. It works perfectly well, and all of our tests confirm that it works exactly as designed. But I think the design itself is flawed. Plus, there’s tons of additional features we could develop on top of this code if we re-wrote it.

Why haven’t people asked for this rewrite though? Well, because they frankly haven’t thought of it. As developers, we know more about what is possible and what is there, and it’s our duty to let our users and product management know what could be made possible.

I just had a long chat / discussion / argument with one of our product managers. In the end, I had him excited about what we could build…but it took a lot of convincing.

Frankly, I’m not happy if I just build the features fed to me through the management pipeline. I’m an inventor at heart, and I’m just not satisfied if I’m doing just I’m told. If you give me an established product, with a large customer base, and a sales force that is poised to strike when they get a feature with which they can hit the pavement running, I’ll come up with a ton of ideas to make that happen.

I suppose what I’m saying is it’s not always the right decision to do the obviously safe approach. Sometimes you just have to set fire to something that, on the surface, looks healthy and “good enough”. Learn from what you have, and replace it with something 10x better. From the ashes, hopefully you’ll build something that nobody else in the market place has. From that your company gets a competitive advantage, and as an inventor, I get personal satisfaction that I’m making our product better, and am earning my keep.