top | item 22112369

(no title)

hasbroslasher | 6 years ago

Parable: Company wants to move "into the cloud" and adopts AWS managed services or Kubernetes to recreate and re-platform existing and functional, though sketchy, on-prem services. "Agile coaches" and "Solution Architects" advise rewriting the old code because of its fundamental alien-ness in a cloud-only environment. So it's a rewrite. But of course, the re-write doesn't work, primarily because of fundamental misunderstandings about what properties allow software to scale across many machines, in many time zones, running processes 1000's of times per day. So it becomes necessary to either cut losses and re-write the re-write or decide to start iterating now on the crappy re-write to make it closer in terms of functionality to what already existed in the crappy on-prem systems - which begs the question of why you didn't just iterate on the original sketchy code in the first place.

There are times when rewriting does make sense - rare though they may be. I've only seen a few, and they always had to do with improving stability and reducing the potential for bugs. None of them required you to use the latest shiny to "completely reimagine what software could be doing for your business". I've helped to rewrite subscription-management systems that ended up noticeably reducing churn and cutting out spurious chargebacks from customers who couldn't navigate our bug-prone subscription service wasteland. But some refactors are so labor intensive that they amount to re-writes, even if you're using the same tools and languages. Some code is acutely awful and it needs to die for people to be able to go to sleep at night without having to drink a fifth of whiskey beforehand. Some atrocities don't need to exist.

But, again, if the reason for a refactor or rewrite is summed up as "we're bored and want to play with these new shinies" then you are in for it. If rewriting provides you with some sort of new business capability or fundamentally changes a business process drastically for the better, then go ahead. But in my experience, if a technology or paradigm is fundamentally "so much better than what we do now", then it should work so well with what we do now so well that it doesn't require fundamental rewrites of large software systems. So rewriting things in Python or C++ is great, or using Kubernetes instead of Lambdas or whatever is fine, but it's more important that these paradigm shifts can be incremental rather than a complete recreation of what already exists, that the gulf between refactoring and rewriting can be relatively small instead of two completely different processes.

discuss

order

No comments yet.