Failure is always an option
Sun 31 Aug 2003, 10:31 PMTweet
by Ben Langhinrichs
In a recent article in the New York Times, Henry Petroski, writing about NASA, makes the point that "failure is always an option", and that engineers understand this point, while managers often do not. Additionally, he describes engineers as pessimists who basically understand all that can go wrong, while managers are optimists, who just don't see the possibilities. I am not sure where software developers fall on this spectrum, in general. I think, to the extent that we can be seen as a single group, that we fall somewhere in between. We are much less bound by physical laws than engineers, but we are usually aware of the difficulty of making complex code do what we want. I say usually, because there seem to be some developers who will promise anything and confidently assume they can deliver, then act surprised when delivery doesn't happen, or doesn't happen on time and within budget.
Now, I have always been proud of my ability to overcome the impossible. I had a colleague at a former job who told me that whenever he wanted to be sure a difficult technical problem would be solved, he would make sure to tell me publicly that it was impossible. I would then work all night to prove he was wrong. No wonder he became a manager and I became an entrepreneur. Yet, I sometimes wonder if we, as a theoretical group, don't borrow trouble for ourselves with this attitude. Engineers come off as a somewhat more level headed group than software developers, partly because their failures are usually acknowledged early and in the factory. Sure, there are exceptions, like the tires which came apart on the SUVs, but most engineering failures are caught earlier. With software, our failures tend to be very public, since they are often caught by the public.
Microsoft is in the midst of its new Trustworthy initiative, which is supposed to herald a new era of safe, secure software. Unfortunately, so far they are mostly exposing just how untrustworthy they are at building secure software. Part of their problem is that they have adopted the mantra "Failure is not an option". Nonsense. Failure is always an option, and the sooner we admit it, the sooner we build software that assumes it will be hacked, and guards against it, the sooner we work together with customers to manage the patch update system more sanely, the sooner we adopt a vigilance not seen yet in Redmond.
Do other software vendors do better? Some do. IBM has always understand architectural integrity better than Microsoft, which lends a degree (sometimes a high degree, sometimes not) better security. Other vendors do better or worse. Open source software, which seems like it would be highly prone to hacking since the source code is available, is often surprisingly resilient, because everyone knows the source code is available, so the developers assume failure is an option. At Genii, we understand the concept, but I don't know whether we walk the walk as well as we talk the talk. It is certainly something we try to do, but, after all, failure is always an option.
Copyright © 2003 Genii Software Ltd.
What has been said:
44.1. Tom Duff (09/01/2003 12:22 PM)
Very good posting, Ben... I have often been told that I am better than I think I am, and that I play down my abilities. I guess it's because I generally tend to "underpromise and overdeliver". If I can set the expectations of the users "correctly" (IMO), then I give myself the room to explore other options if I run into trouble. If things go smoothly, then it looks good when you deliver sooner than expected...