the siren call of starting fresh

Technical debt is hard to measure and estimate. There are code quality metrics you can include. You can measure how long it takes you to implement new features. You can measure how long it takes you to land bug fixes. You can measure how long it takes to onboard new employees, contractors, and interns.

And it seems the first conclusion people come away from any such analysis is to do a rewrite.

Technical bankruptcy is no joke, and it’s hard to justify to your business no matter how bad your current metrics. How do you know this next attempt will be any better? How do you know you won’t just reintroduce the bugs of 5 years ago the last time you went through that rewrite?

Most times, you can’t know, so it’s important to have a couple simple goals.

1. Reduced surface area

You’re rewriting from scratch, so I assume you have a giant, intertangled mess. Keep that pain fresh as you architect this next round. Make your components isolated from one another so you can swap out implementations. You want your goal to be your next rewrite from scratch being just your router instead of everything. Architect for change if you want to avoid history repeating itself.

2. Plan for support

The worst part of many rewrite decisions is that it’s too easy to avoid the question of “should we rewrite” and instead decide “where can I see a clear path: ‘creating my own’ or ‘supporting what we have.'”

Few engineers cannot think of at least some green field next steps. We all have started tons of projects. A rarer skill is in assembling the tools, information, and processes to support a project. When you get a bug report, what do you do? Will you have stacktraces? How will a customer get you those? What was the current application state at the time of an error? Can you reproduce the error if the customer cannot remember their steps? Is this environmental? How should the code have behaved?

On the other hand, before going to the rewrite, you should consider if there are ways to accomplish these same goals from the current code base. Instead of rewriting from scratch, refactor or use the facade pattern to make it look like you have a smaller surface area. In my experience, this is easier than you think. Learning to support, on the other hand, is not. Unfortunately, it is also really important. Until you can learn to do this, you will be tempted by the rewrite off ramp every time.

Advertisements

About joeldart

I am a 29 year old software developer living in Indianapolis, IN.
This entry was posted in dev, Uncategorized. Bookmark the permalink.

One Response to the siren call of starting fresh

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s