News for hackers. Stuff that matters.
Re:Long Term Refactors by mixmastamyk on Saturday January 27, 2024 @06:45PM (#39161025)
The crux of the classic Spolsky piece about avoiding rewrites is that you’re probably not “smarter” than the original team. True enough.

But, sometimes you are. As a well known example, someone rewrote http/urllib in Python as requests and urllib3. Better on perhaps every single metric, often substantially. Ban rewrites and it wouldn’t exist.

My own example, a recent modernization of an ETL project. Original code was a rickety, amateurish, impenetrable mess written in Java transcribed into Python. Loops over loops over loops ten layers deep—would often get lost tracing a bug. Author didn’t understand argparse or logging but used them everywhere. Author didn’t understand absolute paths so there were a dozen and a half custom path join functions sprinkled around the codebase because std path.join didn’t work with relative paths starting with a slash.

For new feeds, over two years I built a brand new streamlined (half the code), dare I say elegant replacement, with tons of quality of life and efficiency features. Like shell completion, syntax highlighting for interactive logs, and conditional download (304) handling. Headline feature, encapsulation of the entire model update process with a single manager method that does almost everything that took bespoke code written forty separate times in the old classes.

As the old feeds are going away all the crap is inching towards /dev/null. Can’t wait for the celebration. Gonna crank Kool and the Gang, I tell ya. :-D

Re:Long Term Refactors by fl0ki on Saturday January 27, 2024 @08:35PM (#39161690)
You've highlighted a difference in rewrites I think is worth recognizing.

urllib -> requests & urllib3 is an example of a rewrite that does not preserve the original interface, which means it can fix more things but it has to convince people to adopt it for that to matter. More subtly, it means the old version still has to exist and still be maintained in some form. Best case, the old version wraps the new version, but even that can be a pain and in some cases can even limit the evolution of the new version.

Other kinds of rewrites preserve the old interface in all valid cases. They may be a lot more difficult because of their constraints, but the constraints also free you from having to make design decisions. When you're done, adoption shouldn't be a problem at all, and hopefully nobody ever has to maintain the old code in any way.

That's a great story of a much needed rewrite. Enjoy the well earned permanent retirement from dealing with that.

Re:Long Term Refactors by mixmastamyk on Sunday January 28, 2024 @06:48AM (#39164768)
If you keep substantially the same interfaces, I’d call that a big refactor rather than a rewrite, though it gets blurry at some point.