The hype of rewrites

James Hague’s discontinued Programming in the 21st Century is one of my favorite programming websites. I like the writing, I like the lack of “web 2.0” widgets to seek popularity. I like the short, carefully written articles.

I just read Follow the Vibrancy, one of several articles where Hague talks of communities formed around a beloved technology, that don’t seem to make things with that technology. Follow the Vibrancy looks in the opposite direction: communities where many things are being built.

Vibrancy is an indicator of worthwhile technology. If people are excited, if there’s a community of developers more concerned with building things than advocating or justifying, then that’s a good place to be.

I agree, with reservations (why are there always reservations?)

A thing I have seen quite a bit of is the desire to apply an idea everywhere, to rebuild everything with a particular tool or technology. The drive to rebuild from scratch generally makes me suspicious when the reason given is technological.

Rebuilding from scratch is one of those strange things that are unexpectedly easy to sell inside companies: The existing software is old—is how the justification begins. Nobody has looked at the code in ages. It was written in Lisp or C++ or something old anyhow. Why don’t we rewrite it from scratch? Going to be great. We can follow modern practices, use OO, CI/CD, whatever, get burn-down charts, measure velocity, and parallelize work among our team of juniors with [insert-language-du-jour] skills but few years of work experience.

Politically it’s a win. The people paying the checks like young, fungible “resources” that are easier to push around. They can name-drop the technologies they’re using with their industry peers and get approving nods. After some time, questions will start to be asked about progress. The new software is not yet ready. The team doing the rewrite will pull heroic work weeks, some of them may experience burnout. Milestones will be reached. Rounds of kudos then, for the young team pulling all-nighters, the heroic middle management, and the visionary top management who “believed” and got the company out of the dark ages.
One would think they had replaced the old company vehicles with new models with better fuel economy and the latest safety improvements.

Instead, the new code has likely thrown the baby with the bath water. The team will need to rediscover bugs the old code had long fixed; they will be dragged, kicking and screaming, to cope with complex use cases the old team had learned to wrestle with long ago. The users who remember the old software will enjoy the fresh coat of paint, and will not lament the lost features too loudly because it will not be politically advisable. The company will insist, inwards and outwards, that the rewrite has been a success.

Corporate dysfunctions such as this one happen all the time, and can drive a lot of demand for some technologies. You meet managers with little technical acumen who wax lyrical about reconverting their company data corpus into a data lake with Hadoop, or about redoing their IT department with DevOps practitioners and containers, or somehow finding an excuse to bring in blockchain or AI.

At heart I agree with Hague’s original point: a community that is excitedly building things is a good place to be. But vibrant also gets applied to Las Vegas.