1. 20

  2. 8

    Programming management will continue to deserve its current poor reputation for cost and schedule effectiveness until such time as a more complete understanding of the program design process is achieved.

    Actually we have a pretty good clue these days…. but we need to update the old maxim “Those who can’t do, teach, those who can’t teach, become project managers.”

    We insist on appointing those who (sometimes wilfully) don’t understand program design as project managers.

    We build systems like the Wright brothers built airplanes — build the whole thing, push it off the cliff, let it crash, and start over again.

    And this is actually A Good Thing.

    The rule is Make it, Make it Work, Make it Correct, Make it Fast, Make it Cheap.

    The best thing you can do to accelerate the process to reduce the cycle time between build, crash, fix and build again.

    Production of large software has become a scare item for management. By reputation it is often an unprofitable morass, costly and unending. This reputation is perhaps deserved.

    Management have become a scare item for the production of large software. They have a reputation of demanding a profit from the unprofitable, insisting on costly misfeatures, and demanding unending changes. This reputation is perhaps deserved.

    Software production takes us from the result of the design to the program to be executed in the computer. The distinction between design and production is essentially a practical one, imposed by the need for a division of the labor. In fact, there is no essential difference between design and production […]

    Curious… they spotted the need for “configuration as code” decades ago… except for decades “production” was dominated by customer service reps who, if you were really really really lucky, would stash the customers config on a tape somewhere…. but odds on the customers config was “secret” and you can never access it.

    The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from.


    Users are interested in systems requirements and buy systems in that way. But that implies that they are able to say what they want. Most of the users aren’t able to.

    Or worse, they say what they want…. but its expressed in terms of a technology a decade old.

    We should have feedback from users early in the design process.

    So long as everyone understands that if a system is really valuable… it will change the way the user does business.

    On programmer performance (compare with the essay Great Hackers by Paul Graham):

    I have a question on the huge range of variability of programmer performance. Are similar ranges found in other engineering areas? [..] The variation range in programming is in fact greater than in other fields.

    I find the largest variability between programmers is what they think is Good Software, and they’re ability to articulate their believes and reasoning.

    This variability accounts for most of the perceived variation.

    Alas, like the difference between left and right on the political spectrum…. everyone agrees on the axiomatic Goodness Motherhood and Apple pie.

    It’s the unstated relative importance assigned by each individual person to each Good thing that derails all discussions on the subject.

    We are starting gradually, and building up. My motto is ‘do something small, useful, now.


    Large systems must evolve, and cannot be produced all at one time. You must have an initial small core system that works really well.


    System testing should be automated as well. A collection of executable programs should be produced and maintained to exercise all parts of the system. […] As an output of a test validation run, each test should list the modules it has exercised, and as well, should list the interfaces and tables it has tested. It is important to document success, as well as failure.

    Test automation is without doubt the largest and mostly costly source of failure in the whole industry.

    Usually :

    • Because the wrong testing is done at the wrong level for the wrong reasons. (See integrated tests are a scam)
    • Software is not designed to be testable.
    • Test automation is a second class citizen to features.

    A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.

    Sigh. Yup.

    1. 1

      “Management have become a scare item for the production of large software. They have a reputation of demanding a profit from the unprofitable, insisting on costly misfeatures, and demanding unending changes. This reputation is perhaps deserved.”

      Yup, yup, yup, yup!