1. 4
  1.  

  2. 5

    Tried to comment but I think I used the wrong box:

    You never need to rewrite, if you’re willing to refactor continuously. The best systems I’ve worked on have followed the lava layer “antipattern” (which I don’t think is an antipattern at all). At any given point in time the codebase has parts that are up-to-date, parts that are following older patterns, and parts that are horribly crufty and no-one understands. This is the normal state of things, and you design your workflow such that you can work on the system in this state. That way you preserve all the organizational knowledge that’s reflected in the codebase, because you’re never rewriting — just continuously evolving the codebase.

    1. 2

      You never need to rewrite, if you’re willing to refactor continuously.

      Agreed. The refactoring will eventually look like a rewrite, but you have to keep doing it. I found the article to be short-sighted. “Coding for Maintenance” would have been a better theme (and better practice).

      To be fair, obsolescence does happen, particularly when no maintenance takes place. This is just as much a business issue as it is an engineering one. As one who has mainly been on the engineering side, I sometimes read the tea leaves and see the obsolescence coming from the business end. It’s times like that where “coding for obsolescence” isn’t actually a bad strategy.

    2. 2

      A common refrain you hear in software development is that of death by a thousand cuts.

      Never heard it in this context.

      The result: a massive effort to refactor the offending code. Or maybe it got so bad that the only way out is a complete rewrite.

      One should be careful not to go the CADT way. It’s usually possible to rewrite even core logic while keeping most of the code, and it’s usually worth it. Because the CADT model does led you to “version 0.8 followed by version 0.8, which is then followed by version 0.8”.

      Componentize and compartmentalize your system with the expectation that some day you’ll need to replace each part.

      So modular programming then? Alrightie.

      Though often when you rewrite a module you want to change the API, which will drag changes in other modules. Still, good architecture is good, and not only because of rewrites — clean code helps you to avoid rewrites, and works better on top of that.

      For a start-up the product may look nothing like it did 6-months prior.

      It’s a mindset: plan for obsolescence, nothing lasts forever. We’re not building the pyramids.

      For some reason we have this idea, almost like pyramid builders, that we’re building this gigantic obelisk that will stand for thousands and thousands of years. I apologize to the embedded programmers in the audience because those things are kind of true. But for the rest of you who are writing web apps, or skins around databases, as I like to call them… — Tef

      Sure, we can’t always avoid morphing software, and it’s not even necessarily our (programmers') fault. But maybe we should aim to create obelisks? Maybe one of the reasons that code is so flaky and unmaintainable is that when we write it we’re already planning to throw it away? Software can be “done”. Taylor UUCP, for example, was not releasing for a decade or so, and the only third party patches flying around were to make it compile on newer platforms. I expect much Unix system software (stuff like ls and awk) to be quite stable.

      1. 2

        KISS, DRY and SOLID.

        1. 4

          DRY as a dogma can bite you though. DRY requires good abstractions.