1. 4

  2. 3

    I prefer my grandfathers axe…..

    I have my grandfathers axe, my father replace the handle and I replaced the blade…

    1. 1

      Your model can still be used in this context, as the question can still be asked: “Is it the same axe?”

      This was the (secondary) point I got out of the article, along with what I felt was the primary point: “Replace components of your axe/ship/software gradually and carefully, never start from scratch,” as some of the mess that you want to rewrite may be fixes.

      I would also encourage clicking through and reading the article he linked, https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

      It is an excellent read.

      1. 1

        Yup, read it pretty much when it came out, by gorrah, nearly 20 years ago!

        It’s being an ongoing point of (robust) debate between myself and one of my colleagues.

        He tends to favour rewrites (if I might try summarise what I think he has said…) because…

        • You can drop a whole bunch of obsolete cruft.
        • The code and design has become broken over years.
        • There are much better ways of doing the same thing.

        I tend to argue, pretty much as Joel does, that a lot of the cruft is hidden business requirements that you’re going to (painfully) rediscover.

        I’m not convinced that the people rewriting the code are magically so much better than the people who wrote it in the first place.

        So I strongly favour…

        • Vigorous Deprecation processes to actively drop old requirements and code (and get feed back from the business end early if is there is actually still some weird hidden requirement for it.)
        • Continuous refactoring to clean as you go.

        If you’re at the point of seriously considering a rewrite… maybe you should be stepping back and asking a larger question…

        This is the peak evolution of a product that was required, maybe 20+ years ago….

        If you were going to rewrite… wouldn’t your efforts be better directed at creating a new category of product that addresses the current market?

        A common misconception is that “my product is an excellent and expensive chunk of kit, people are going to appreciate and fall over themselves for upgrades!”

        Alas, the true answer sometimes is, your product is a component in an amazingly expensive and complex mega-system… dealing with churn created by your upgrade costs way way more than replacing it with anything that’s backwards compatible so we don’t have to churn the rest of the monster.

        1. 1

          Agree with everything said - I will say, however, that the sentiment you identified in the statement below…

          I’m not convinced that the people rewriting the code are magically so much better than the people who wrote it in the first place.

          … is just as, if not more harmful, to a a body of work (whether it be code or not) than the method chosen to maintain or upgrade said body of work.

          Once any method of doing any work is ascribed to the worth of an individual as a person - things break down fast.

          It’s obvious you know this, too.

          It sucks being thought of as “less than,” because you tried doing what made sense to you in a given moment, just as much as it sucks having others misinterpret your actions as being those of an individual On a Mission, accountable to no one.

          1. 1

            I often say to people, you should assume that every line of code was The Best Possible Line of Code that could have been written on That Day, given the Best Practices of That Day, given the constraints and goals of That Day, and the skills and knowledge of that person on That Day.

            Today is not That Day.

            The best practices have evolved, the constraints (ram/rom/mips/disk/release date/….) and goals (kpi’s/requirements/…) are substantially different, and we all should be improving our skills and knowledge every day.

            So yes, we can (and should) change that line to be a better one, matching today, but with the humility to know our line will also look terrible in a couple of years time.