There Is No Such Thing as a “Maintenance Project”

Recently I joined one of the STX Next projects as part of the development team. As many of our projects, it is not a greenfield project — there is an existing code base already (Google App Engine with Ionic, in this particular case) that we had to work with. I’ve looked through the code, and, let me put it this way: there was room for improvement (think 3 thousand lines in a single Python file, hundreds of lines in a single function, deeply structured messy data in a JSON property in the database). However, there was talk of a “grand rewrite,” we would have to support the old system, but at the same time work would be done on a completely new system that would be much beterer [sic].

But then, disaster struck. We heard that the new system was out of scope for now. It was postponed until later. In our weekly retrospective meeting, this immediately bubbled to the top as a huge issue: the project turned out to be a maintenance project, they did a bait and switch (“build a new system — haha, no, just hack on the old one!”). We were tricked. Fail. Disappointment.

I don’t think the “this is maintenance only, nothing to do here” attitude is unique to this project. I’ve seen it in other projects too. Let’s face it — few projects in the world are greenfield (for long). There’s almost always a existing code base, and (seemingly) no time to rewrite all the things.

So here comes my controversial statement:

Greenfield is overrated.

Greenfield, to start a project from absolute scratch, is a dream for many. It’s just like a hobby project, you can pick the technology you like, create a clean repository and set up everything exactly how you like. You know, how it should be done. However, there’s a tragic part to such projects that quite often doesn’t surface in a hobby project (because they don’t last that long, or are not that big):

Greenfield is only greenfield for a few months, tops.

After a few months, the technical debt starts to drip in. Your old architecture starts to fail. Requirements are different than anticipated and no longer match your code, and large parts of the code base you wrote hugely misjudged reality.

And here’s the kicker — _this time you have nobody to blame but yourself._

In a project where you inherit a code base, you can laugh at your predecessors. Hah. Such an obvious architectural mistake. Such a dumb data model. Idiots.

When you started it yourself, it becomes painfully clear who the idiot really is. Or, in fact, that anticipating the future and doing things right isn’t that easy after all.

You’re in a mess, so what do you do? Rewrite all the things!

It’s fun, but in business a complete rewrite is a shortcut to disaster. I’ve seen many examples in previous jobs, the rewrites either were too big of a project, failed, were canceled, or in the case of a super patient company — took years longer than anticipated.

Is there an alternative?

Often, yes: iterative improvement. The scout rule — leave things better than you find them. Cut up the 200 line function into 10 functions. Layer cleaner interfaces on bad parts of the system, slowly swap out the bad parts, piece by piece. It’s still rewriting, but at a much smaller scale.

But… can you really spend time doing that? Don’t you need approval? Don’t you need special “refactor stories” (“As a code base, I would like the be cleaned up so that I’m not a huge mess”)?

I believe this is where skill comes in.

Every change you make is some sort of rewrite. Perhaps you’re just rewriting a line, or a function, but you still rewrite. Piece by piece, bit by bit. The skill is to create the opportunity to nudge things in the right direction in a meaningful way. A hundred nudges lead to a significant bump in quality, and that’s how software gets better. In my opinion, finding and creating those opportunities is what make good programmers great. Kaizen, y’all!

My broader take-away is this:

There’s no such thing as a maintenance project, there’s only a maintenance attitude.

All software development involves maintenance. Unless you believe your project is technically perfect, and there is nothing to improve (hah!), there is always opportunity to clean, fix, and learn plenty of things as you go. Again, every edit you make is a small rewrite, and dozens, hundreds, thousands of tiny rewrites make a good system.

The skill is to see the opportunity to improve. To slip in the thing that will make things better, no matter the pressure to deliver.