Refactor vs Rebuild: New Years make New Beginnings

We’re at that time of year where everyone wants to start something new. We have a flood of articles and blog posts about “what I’m going to do differently this year” and everyone wants to [choose: lose weight, read more, get out of debt, get that new job, etc, etc]. If they’re lazy, this urge will last about a week.. aka it’s probably done by now. Alternatively, if they’re motivated, they might make it to February.

At the end of the day, it doesn’t happen because starting something new is HARD.

Alternatively, in software development, we’re spoiled. We can write a single line of code and do some interesting things. If we add a framework, that single line of code is backed up by thousands.. and can do even more impressive things. At Twilio, it’s cool watching someone get excited that their three lines of code just made their phone ring.¬†Unfortunately, we can take this too far..

I can’t tell you how many people have pitched me to “rewite web2project using [framework x].” At first pass, it sounds like a great idea. We can lay the foundation for doing things “right.” We can use the latest and greatest tools, technology, and concepts. Even better, we don’t have to figure out all that old crappy code! It’s open source so it’s free anyway. Everyone wins!

How many times have you looked at an application and thought “I could rebuild that in a weekend!”

Be honest. You’ve done it. I’ve done it. It’s seductive and sounds so good..

But it doesn’t take into account a whole flock of considerations:

  • First, there are many lessons learned and strategies embedded in the current code that are simply lost. Odds are there’s a reason it was done that way before but now you don’t know why. And yes, sometimes that reason is as simple as “we didn’t know any better.”
  • Next, you have to spend months – or even years – getting back up to the point of having a functional application. During that time, you’re not moving ahead, you’re just trying to catch up to where you were originally.
  • Next, you have to continue supporting the old system because people are still using it and even after you release the rewrite, they don’t upgrade immediately. WordPress has a one-click upgrade and they still have to convince people to upgrade regularly. Is your app harder or easier to upgrade?
  • Next, it decimates any sort of plugin, extension, or module community and can reset you back to zero. We dealt with this in web2project and it’s taken years to convince some maintainers to update.
  • Finally, it kills the community because they don’t know where to contribute. Should they put their limited time and effort into a codebase that will be killed or the codebase that doesn’t work yet?

At the end of the day, what we have is technical debt. It’s stuff that slows down current development by making it more expensive. It suck but declaring bankruptcy and attempting to start over is rarely the answer.

Instead, we should figure out a strategy for Managing Technical Debt.

Are you interested in API Design? Check out our new book "A Pragmatic Approach to API Design." In it, we cover the basics on why you might need an API, how to get started on modeling your API, and finally some design patterns and anti-patterns to be aware of. Available soon from LeanPub