1. 11

  2. 14

    Someone recently wrote a response, looking at case studies of how starting over works in practice: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22

    His conclusion? There are plenty of cases where a rewrite makes sense, and the “biggest mistake” mentality might have ruined Spolsky’s own product!

    1. 3

      I remember working on a project that had been started long before I got there. It was written in idiosyncratic Perl and only used hand-spun Perl libraries (as in, they rolled their own JSON parser and CGI parameter-splitter libraries rather than using the CPAN JSON module or the Perl standard library’s CGI stuff). It did not use any features introduced into Perl since like 1998 (this project was in 2012 or so), though the lead developer admitted there was no backwards-compatibility requirement. It used Perl’s object-oriented programming features, but in a bizarre way…lots of singleton objects and no class hierarchy anywhere.

      There was absolutely no choice but to burn the thing to the ground and start over from scratch in Python.

      1. 4

        I mean, that sounds horrible, but start from scratch is definitely not the only option; you could also start a python ‘sidecar’ project and incrementally move functionality across until there’s only vestigal perl remaining.

        1. 3

          The expression I heard that stuck was “he is writing twenty year old code, today.”

          1. 1

            Is that a problem? Isn’t there a ton of 20 year old code out there that’s still deployed because it works? How much of a modern Linux distro is really projects that started 20+ years ago, and where modern code added to them needs to adhere to that style? Couldn’t this be said of the kernel itself?

            1. 1

              I think you are missing the point of the expression. 20 year old code is difficult to work with, often very fragile, because the circumstances and assumptions under which it was developed have changed. And then it’s been hacked on for twenty years, slowly drifting away from its original design documents. It is the inevitable result of code that’s worked for 20 years, which is fine, but it’s madness to build those deficiencies into the code from day one.

          2. 1

            Isn’t this the core of Joel’s point? That trying to read and understand an existing codebase is hard? So although the original author might have been thinking about the problem a certain way, to a reader it just looks “bizarre.”

            Thought experiment - do you believe that no other developer could see your code the way you see this developer’s code? Perhaps another new person arrives in a few years, and they’re more familiar with some other language; will they understand your Python implementation or instead conclude that “there was absolutely no choice but to start over in Go/Rust/C#?”

            1. 1

              I’m not so naive as to think my code could never look like gobbledygook to other people, but my code at least follows some semblance of “common practices” for the language(s) it’s written in. This was tens of thousands of lines of uncommented Perl, not following any particular coding style or convention, and using entirely hand-rolled libraries instead of stuff readily available in standard libraries. Just the auditing to figure out if those hand-rolled libraries were secure (they weren’t) would’ve taken longer than we had on the project.

        2. 5

          Drive to rewrite everything is very strong (at least for me) for simple reason - you have more information after the fact, you understand problem better, so you can create better abstractions, less code, easier to maintain (if you still maintain that is, without maintenance code complexity is irrelevant).

          Also, the problems arising for big players are not the same as problems arising in typical corporations. Rewriting Word is probably bad idea given its level of usage, but rewriting from zero something without that level of exposure is way easier.

          The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive….. …. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle.

          Not completely true because it ignores software deprecation. Why would I need fix for a floppy today ? I certainly don’t because nobody uses floppy today. Also, yes, it acquires bugs just by sitting there, because standards change, and some are enforced (example: SSL). While orginal devs would probably declare this not a bug because it couldn’t be known in advance, for users that can’t access functionality its a bug. If you made the software that uses standards, you should follow them if standards are changing in a manner that blocks your users.

          So, old code has been used in specific context and it changed, so its not irrational to adapt the code.

          1. 3

            My team did a big rewrite a couple years back (with eyes wide open about implications), and I debriefed it in “Shipping the Second System”.

            1. 2

              I feel like the real solution here is to refactor code. I really enjoyed https://jacquesmattheij.com/improving-a-legacy-codebase/ as a set of guidelines for how to progressively improve a piece of software. I think if you can split out functionality into separate components there is even the possibility of changing programming languages in an incremental fashion.

              1. 2

                This is a well-trodden subject by now, but I rarely see anything other than “big-bang rewrite and hope it works” vs “suck it up and leave it be” as if they’re the only two options. For example, you could use something like Scientist for a piecemeal rewrite, using the existing codebase as a test suite.

                1. 2

                  Wait, I am doing this right now! I still think it is the right move. Why? I am sidecar replacing a product that never really went beyond MVP and was stuck in the hands of one person for nearly a year. The haphazard nature of it goes beyond just the code itself. That being said, isn’t this just the second system problem?