What if?

 In one of my favourite Futurama episodes, Professor Farnsworth displayed his “What if”  machine.  It allowed a projection of the future based on the “what if” assumption made by one of the characters.  In an earlier post I discussed “Geekonomics” by David Rice.  Rice meticulously researched his topic, citing many references to support his case.  The main difference between his book authoring and my blog writing is the time spent in preparation.  This blog is far more speculative and without the time spent looking into corroborating evidence makes a far less convincing case.  After all, blogging is not journalism

So, having cranked up the “What if machine” let’s give it the opening statement:

What would happen if adhesion contracts of software manufacturers were not permitted in court?

The full pretext is really that software manufacturers would then be held liable for damages caused by insecure or buggy software.  Differences in the laws between countries, makes this an issue that would not work out as simply as I would have you otherwise believe.  These differences are beyond the scope of this discussion.

Insurance companies play a large role in protecting companies from paying damages.  Looking at the automotive insurance industry, we can see that the track record of a driver plays a part in the insurance premium the driver is charged.  There are estimates of how much insecure and buggy software costs industry and the general public – so it can be reasoned that insurance companies will know approximately the funds required to cover the payouts.  On the flip-side how to rank software development companies such that their premiums are “fair” (read competitive) will start off being very “hit and miss”. There is little statistical analysis of developer traits and development practices that reduce the likelihood of insecure software.  “Better Quality Assurance” may be the answer, but defining what this means is problematic.  As such, insurance companies are unlikely to be able to set reasonable premiums for software development companies.  

Another issue which would need to be confronted relates to open source projects.  Should they be immune to prosecution under some “Good Samaritan” act?  Some open-source projects are likely to be profitable due to on-going service / maintenance contracts.  Others aren’t…  Should the profitable companies be exempt on the guise that the software they provided was “free”? 

Once insurance companies become involved, there’s likely to be far more interest in good development practices.  Defining good practices and proving companies stick to them appears to be a great way to improve overall software quality.  (When defining “quality” in terms of “defect severity and defect count”).  Until reliable metrics are available to insurance companies, it is likely that liability insurance premiums will be based simply upon the upper limits of payouts.  I would anticipate that most insurance companies would set their fees “fairly high” – but what this means in practice is beyond even my advanced powers of speculation and making things up…

High insurance premiums would hit the small software companies the hardest.  They either have their profit margins hit hard, or they run the gauntlet of not using a liability insurance policy.  It’s easy to speculate that these companies would be the first to disappear from the market.   With insurance, they may no longer be profitable, without insurance, it’s only a matter of time until an expensive date with the courts…

Larger / more profitable companies will start driving demand in the insurance market.  In an effort to provide competitive premiums, insurance companies will need to start defining the software company’s equivalent of “careful rating 1 drivers”.  Chances are this will lead to more practices being established to standardise the way in which development staff are selected.  Developers with formal learning (such as recognised degrees and diplomas) and/or up to date certifications will become more highly ranked than “skilled amateurs”.  Demand for courses may well be overwhelming at first – leading to a shortage of qualified developers.  Alternatively, some highly skilled but officially unqualified developers will likely leave the industry – leaving the computing industry somewhat poorer as a result.

So, will the abolition of adhesion contracts in the form of End User Licence Agreements lead software companies to providing higher quality software?  Will this cause a “strive for perfection” at the expense of fast paced innovation?  I can’t tell you the answers, but I don’t think we will need to wait terribly long to find out.  I rather think the current legal position of software companies is akin to the cigarette companies of yesteryear.  They will cling on to their position as long as possible, but sooner or later some clever lawyer will present a position that the manufacturers won’t be able to weasel out of.  When this day comes, the software industry will change…


Wobblers, Idiots and you

There are three groups of riders, wobblers, idiots and you.  A “wobbler” is someone who wobbles around corners slower than you and an “idiot” is someone who goes around corners faster than you.  The idiot is so named because they are obviously going too fast for the conditions.

I do not condone racing on the road, but that doesn’t mean I don’t appreciate travelling at “an increased pace”.  I have my own mental “cheques and balances” by which I ride on public roads.  There are enforced limits I place on myself, which restricts how “enthusiastic” I am on public roads.   What these limitations are, is rather arbitrary; riders of differing skill levels will either be horrified or laugh at my limits – depending on their own wobbler/idiot status.  It is suffice to say that the kangaroo standing on the other end of one particular blind corner and I agree that my “safety margin” was sufficient.

From my own experience, I have discovered “A Speed vs. Effort” effect.  Riding faster, up to a point is easy.  A small increase in pace is achieved with only a small additional effort.  But there is a pace where that changes.  Extra pace is very difficult to come by.  Trying to ride past this limit on public roads is dangerous.  This is the time that mistakes tend to be made and smooth riding ceases to occur.  Ironically, the added abruptness and mistakes are probably slowing you down too.

If you are aiming to rapidly increase your riding ability* you need to push yourself beyond these bounds.  This should only be done under the controlled circumstances of a race track.  Reputable racing schools can undoubtedly help most riders improve their cornering ability / speed, but like most things quantity trumps quality.  In other words, time on track is the key ingredient.

Back on public roads…  Remember that when riding with friends (or strangers) that they will likely be wobblers or idiots (or sometimes both!)  Riding with “idiots” can put you in a nasty predicament.  There is a fair chance that they are only slightly faster than you.  This can lead to you being “dragged along” by them.  If this leads to you exceeding your safe pace, be mentally strong enough to “let them go”.  Sometimes this can take a scare for you to realise that you are indeed riding above your ability.  Sometimes scares turn into panic.  Panic leads to crashes.  Riding with “wobblers” puts you on the other side of the fence…  Regular riding friends probably grow accustomed to the pace you set.  If it’s too fast for them, they will probably come to accept that and wave you on your way.   They will meet up with you at the other end. 

If you are riding with inexperienced riders remember the “do unto others” law.  Did you appreciate being left behind by more experienced riders when you began riding?  Telling a beginner not to try and keep up is only fractionally less irresponsible than expecting them to keep up.  Be kind to them and leave your “fast riding” for another day.


* Suggesting that “riding ability” equates to how quickly you ride is overly simplistic and not terribly relevant for road use.  Your ability to sense bad drivers and hazards are far more important skills to hone when riding on public roads.

Getting serious – Improving Software

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!