At times of stress and sorrow I tend to look back and attempt put things in perspective. I can’t find anything that would put what has happened last week in any perspective.

As I was thinking about what happened, about US and world history, among the many random thoughts an historic article about an important piece of computing history came somehow into my mind: One Giant Leap: The Apollo Guidance Computer.

Here are some interesting tidbits about this wonderful software: “The system ran an executive that handled (typically) about 40 concurrent processes and allowed interrupts from various system sensors as well as astronaut input. It was capable of failing gracefully, which it did during the lunar descent as a radar subsystem began sending too much data to it. It was also robust enough to handle a lightning strike while Apollo 12 was on the launch pad just prior to liftoff.”

Please remember: when this development was happening the term “Software Engineering” hasn’t even been coined yet and people barely started to figure out what would it take to write error-free software. So how big was this program? 72kB in the ROM, used a 4kB RAM for stack and data and the CPU ran at an amazing 2.048 MHz. And it took about 5 years to write.

One of my longtime favorite software gurus, Larry Constantine, gave a keynote presentation at Software Development 2001 conference in San Jose earlier this year.

Here is the last slide from his talk:

• If you don’t know what you’re going to do before you do it, you don’t know what you’re doing.
• If you spend all your time figuring out what you’re doing, you’re doing nothing.

I agree. Feel free to insert planning or design instead of figuring out in the above statement. In an article posted also on foruse.com entitled Process Agility and Software Usability Constantine makes a point that I don’t entirely agree with:

Perhaps the biggest selling point of the agile processes is their weight—or lack thereof. There is simply far less to them than to the leading heavyweights, which means potentially less to learn and master. That does not mean that agile processes are easy, any more than it means that agile process can substitute for programming skills and developmental discipline—but it does mean that there is less to explain about the processes themselves.

Larry Constantine

I think that learning the process is a small fraction of effort, almost negligible, by comparison to learning all the other skills that a software engineer needs to know to perform his or her job well. So far all people that I talked to who were good at design, or requirements, or user interface design, or any of the other skills required to create great programs, had already created for themselves a process that closely resembled one of the “published” processes.

Later, in the same article he makes another interesting point. He is in full agreement with Barry Boehm on the most important factor that determines the outcome of a software project: the quality of the people.

All of the agile methods put a premium on having premium people. They work best, if at all, with first-rate, versatile, disciplined developers who are highly-skilled and highly motivated. Not only do you need skilled and speedy developers, but you need ones of exceptional discipline willing to work hell-bent-for-leather with someone sitting beside them watching every move.

Larry Constantine

This brings us back full circle to the same issue that many of you already heard me talk about: How do you become and then continue to be that premium developer? We’ll leave that topic for later.