Just Try Again
It’s funny because it’s true:
A Software Engineer, a Hardware Engineer and a Departmental Manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt, scraping along the mountainside. The car’s occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?
“I know,” said the Departmental Manager, “Let’s have a meeting, propose a Vision, formulate a Mission Statement, define some Goals, and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way.”
“No, no,” said the Hardware Engineer, “That will take far too long, and besides, that method has never worked before. I’ve got my Swiss Army knife with me, and in no time at all I can strip down the car’s braking system, isolate the fault, fix it, and we can be on our way.”
“Well,” said the Software Engineer, “Before we do anything, I think we should push the car back up the road and see if it happens again.”
In all seriousness, I can’t recall a single week that I haven’t done this exact thing at least once: Geez, I dunno, just run it again and see if the problem recurs. I don’t know if it’s a sad indictment of the state of software engineering or a not-so-subtle hint that software engineers deal with thousands of variables in even the simplest of programs.
