1. 5
  1.  

  2. 13

    Someone for whom it’s equally easy to shift the building up and put a new foundation down as it is to change the colour of the door. Someone who can easily reach past the layers of wood and insulation to add a new room below.

    If you don’t utilize the advantages of software (easy to delete, easy to redo, easy to reuse) when building software, then that’s like treating your helicopter like a car and only flying over roads, and waiting for the cars on the road to move before you move. The helicopter is not a car. It doesn’t have to follow the road. Software is not a house. You can fix the insulation directly.

    In software, a near-complete spec could be the program itself.

    1. 7

      I think that’s only true for small projects. Facebook find it easier to extend PHP than rewrite their legacy code. Also, how most banks are still stuck on mainframes.

      1. 3

        Having a vast cabinet full of blueprints will merely mean before you can change anything, you first have to find and change the blueprint…. a task which is as hard if not harder than changing the code.

        Especially as, odds on, the blueprints are out of date since nobody does roundtripping.

        Or you can look at the problem differently….

        The most precise and concise and readable and understandable representation of software is the code.

        Of course, if you start with a crap representation (aka PHP) and find yourself at the bottom of a hole…

        What’s the rule about getting out holes you have dug yourself into?

        STOP DIGGING!

        1. 1

          The most precise and concise and readable and understandable representation of software is the code.

          That’s like like saying “The most precise and concise and readable and understandable representation of a novel is its text”. It’s precise and complete, but usually not concise. And sadly, it is often the only way to find out how it works. In many projects I would have killed for a 10-line description of the architecture and how it maps to source files.

          1. 1

            You need to learn to skim the data structures… and find where the I/O end points are.

            Give me those things I will navigate via declaration/reference graph around the system like a monkey swinging on a jungle gym.

            OOP gets a fair bit of hate, but I can read the instance variables and immediately say, aha, I have a clue what all this code in this class is doing.

            And I will be faster and more accurate than somebody with a cabinet full of blueprints.

      2. 2

        Software is a lot worse than a house. The space a house lives in is 3d. The space of a software program is infinite dimensional. You can hide all the bugs in one corner and never notice.

        1. 2

          Metaphors are imperfect by definition. I think it’s more constructive to look at the complete analogy and metaphor and see which aspects map nicely and which don’t. Obviously, a programmer intimately familiar with a particular codebase, might indeed be able to change or implement certain features quickly. In other cases, he might not be able to. I think so far the metaphor holds pretty closely. I would distinguish between tasks that require no deep understanding of the architecture (painting a wall, changing a message), and tasks that do (removing a wall – is it a load-bearing wall? – changing a method in the common path – does it break an invariant?).

          One difference, I think, is that progress is a lot more visible in construction. In software, you might think you’re almost done with something, but when you have a closer look it might turn out to be impossible to do after all. It’s also a lot harder to mess things up, due to source control. This is a big point why construction requires more planning: If you seriously mess it up, the house might collapse. If you mess up your software, you get crappy software. The difference is that people can live with crappy software (facebook notifications don’t go away on mobile, I can’t disable linkedin job alerts, twitter fails at loading pretty much anything), but they often die when they are in a house that collapses. Indeed, in areas where it matters (cars, aviation, aeronautics, security, large-scale manufactoring), people tend to be a bit more conservative about ‘moving fast’ (and they certainly won’t encourage you to ‘break things’). Indeed, these are areas where formal methods are more often applied than in the rest of the industry.

          Another difference between construction and software engineering is that (I think) it is easier to spot obvious mistakes in construction. In software, you might have an obvious mistake, but it might be hidden in a big codebase.

          I think the metaphor holds pretty closely when you compare projects of similar size (of course, comparing the ‘size’ of an construction project and a software project is terribly ill-defined). The bigger and the more mission-critical your project, the more you need to plan ahead and ensure safety (which sounds surprisingly much like common sense).

          1. 1

            That is true until physics gets in the way. When a system is concurrent, distributed and runs mission-critical logic, the cost of moving/shifting/changing the software of the system may be considerably higher than using formal methods to specify it.

            Mr. Lamport mentions an interesting example of a chip designed by Intel for Xbox. It has a bug (that was discovered with formal methods, prior to production). Imagen you have 1 million chips deployed all around the world with a bug. So yeah, software systems are subject to physics too, one way or another.

          2. 5

            My bogan uncle, for one. Pretty nice house, too

            1. 3

              It’s exactly where the problem is: building houses without blueprints does work, until some point.

              1. 1

                Continuing with the house metaphor, until an earthquake happens.

                1. 2

                  In software assurance, we try to understand recurring risks and mitigate them where it makes sense. Areas with many earthquakes make earthquake-resistant buildings. Taipei 101 was extra interesting in that it had to be both wind and earthquake resistant, which have opposite requirements. Here’s it working during one of the earthquakes.

                  Similarly, folks in areas with hurricanes build stuff to resist them. There’s even something for flooding now proven in Texas during Hurricane Harvey.