The Value of Code

"Code is first written, then admired, then thrown out in disgust" - Sergey Sundukovskiy

I've inherited code many times. Sometimes it comes laden with technical debt because the offshore developers didn't get proper input. Other times because the business has shifted priorities or direction. And not all that infrequently simply because the developers were not given proper technical direction and leadership, and ran off to do whatever tickled their fancy, modeling whatever they found on a blog somewhere.

I've been sitting on a big pile of code-legacy for a few months. An inherited project that by all accounts generally functions as it should. Sure, it is slow. It doesn't scale. It is authored with some very outmoded patterns that make simple things like adding a model property a full day of work involving touching 10's of classes, instead of one. The API is a bizarre and unnecessary abstraction upon the primary domain model, with layers of DTO's and Transformers. However, the code is neatly packaged, cleanly separated, and generally reasonably well tested and well written; just, by my teams standards, done "the wrong way".

Some advantages - the only real API customer at this early stage is my own front end! The customer base is small and undergoing a private beta. Their primary complaints are around UI/UX (of course!) and in some cases speed.

My development staff was 50/50 for/against rewrite. I believed we could get there with a domain-centric refactor, others believed a redo was called for. I don't believe in change for change's sake - there must be a business value to the efforts or technology is running amuck.

Oh What To Do?

Honestly it is a tough decision what direction to take. On the one hand, it works. On the other, the maintainability is so painful I don't want to touch it, and that is a factor not to be understated.

So we had a Bake Off of sorts. Half of the team went the refactor route, the other half went the rewrite route, over the course of a week.

The outcome I found very interesting. Most bake-offs don't end with getting to eat both pies! Turns out the refactor wasn't as challenging as first thought. Turns out the rebuild-from-scratch got a lot farther than anticipated.

Oh What To Do!?

We're going both directions. The microservice buildout that the second team did will continue forward, and the original refactored work will be retooled to delegate to that service wherever it interacts with those components of the data model. I have heard this referred to as "in place refactor".

Why Did This Happen?

Because most often, web applications really aren't that hard. They are mostly CRUD apps with a few smart areas that do interesting things. What's hard is capturing the business need and offering technological value.

Because refactoring is really only hard if you don't understand the problems in the code you are working with, and/or don't have your alternative solution or design firmly in mind.

Because writing new code from scratch is often painless if you understand the business need and domain, and are reasonably experienced.

The moral of this story, I think, is twofold:

1. Don't be afraid to rewrite code you hate (for good reason) as long as you fully understand the business goals

2. Don't assume rebuilding code (also for good reason) will take longer than repairing bad code.

This calls to mind a good friend of mine I often quote as saying "nothing is ever as easy as you once believed" - it's nice when things sometimes go the other way too - some things are easier than you imagined possible.