1. 30

  2. 6

    Do not ever even attempt a big-bang rewrite

    As tempting as it may be to rewrite, this is absolutely true. You can’t do a big-bang rewrite until you understand the system. There are usually so many hidden requirements that you can’t expect to know them without a lot of effort put in to understanding what is already there. Also, with a rewrite, you’re supporting two systems, not one.

    And yet, it’s the first reaction all the time when presented with a rat’s nest of code. Funny how the brain works sometimes.

    1. 3

      I’ve grown to enjoy refactoring code bases, though I suppose I haven’t seen the worst possible cases (my largest refactors were around 5Kloc or so). It gives you an opportunity to do a sort of problem solving that you don’t get to do during normal development, an increase in the number or regexen or other code analysis tools that are needed to figure out how to do something.

    2. 2

      This resonates really strongly with me, as my recent contract has been exactly this. Since it was my first time working on something as hard to maintain as this, I did a few mistakes and had to build myself a list of steps to make sure no more errors were made. This is basically verbatim.

      1. 1

        Excellent advice in this article.

        1. 1

          “Backup”? Seriously? Who would even think about attempting anything like this without a solid SCCS?

          1. 2

            That point covers more than just source code. It specifically calls out configuration data. That might live in config files with the source code, but it might also be in the database, or in environment variables that were manually set by Ops. Those things need to be backed up regardless.