A while back I read “Geekonomics – The Real Cost of Insecure Software” which discussed at length the problems associated with buggy and insecure software. Whilst stopping short of stating it, the message seemed fairly clear that David Rice believed the answer lived in holding software companies liable and the abolition of adhesion contracts as defined by End User Licence Agreements*.
The book left me with the impression that Rice felt all software developers were solely interested in making money without respecting their customers. The computer programmers I have met have all had a conscience. None of them would purposefully release software which they felt was dangerously insecure or buggy. “Don’t worry, be crappy”, may well be a catch phrase for the industry, but I believe its intents were based on the fact that most programmers are “worriers”. “Natural programmers” concern themselves over a vast amount of details. They think of boundary cases and follow predictions through to see where this takes them. Without some cap to how much thought they can apply, chances are they will achieve nothing – forever theorising on the possibilities. It’s been said before… “Leading Programmers is akin to herding cats”
There’s often been debate about whether software programming could be called engineering, craftsmanship, artistry or something else. Despite people’s best intentions, software has a long way to go before it reaches the stages of engineering. You trust that your car is not about to combust as you travel the freeway and no matter what your innate fears may be, you’ve never got in an elevator honestly believing that it may just break and plummet down to the basement. Would you trust any software running on a PC with your life? (Would you be willing to bet your life on your word processor not crashing?)
There’s nothing particularly wrong with the tools used to develop software. The common languages in use today are capable of providing stable reliable software. (Even if their End User Licence forbids their use in a nuclear power station) The chances that compilers produce the wrong executable code are extremely slim. So, most of the mistakes made in software, are at the “highest level” – the level where most of us live in our software careers. Whilst there is no doubt that there are some very clever developers working on the various common computer programming languages, virtual machines and software platforms, they are still human and capable of mistakes. Which leads to the obvious question: “How do those people get their software right, even though they will make mistakes?”
During my time as a Development Lead, I tried to refine a process that would minimise mistakes making it into production code. Most of those processes revolved around the concept of having more than one set of eyes look over the problem. The truth of the matter was that I never reached 100% success rate and that I was never going to. David Rice was correct in the fact that in most cases there is no compelling reason to strive for zero errors. In fact, the opposite is true: “There are compelling reasons not to strive for zero errors”. Most of these are monetary… If you never release software for fear of it having bugs, you will never have an income. That is not what would be called a sustainable business model.
Software practices such as Test Driven Development and peer reviews are improving the accuracy of software that is written. Ultimately I believe that the number of times a given code stream is executed will largely determine the accuracy of the particular piece of code. It is by no means the only metric for determining the likelihood of having bug free code, but most other metrics express reliability based on code quality. Even the worst written code can be “bug free” and sometimes it is this code that has given years of faithful service. As in testing, Quantity trumps quality, and cares not for well written code! For this reason, code re-use should be at the forefront of your programming consciousness. Most engineering disciplines rely on using as much tried and tested techniques as possible – thus reducing the risk of the unknown. So, if we ever want to describe our discipline as “Software Engineering” and keep a straight face, we need to act in an appropriate manner. Use the code that has gone before you, contribute only to future code what you cannot already find. It is a well worn saying, but one the industry seems yet to fully embrace…
* I’m only too well aware that getting your thoughts across by writing words is open to interpretation that can miss the mark. Maybe David Rice was being more open-minded than I have portrayed him! You will have to read the book and make your own mind up!