'Unbreakable'? Software? Harr!
The joke that shouldn't be a joke
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
As sometimes happens, I got an email from a reader after writing a piece for Reg Developer. This time, the piece in question was Testing assumptions and the big stack and, as perhaps you will see, the email brought a guffaw, and then a thought.
"I enjoyed your article 'Testing assumptions and the big stack'," wrote my correspondent Oscar Leeper (thanks, Oscar, the cheque is in the post). "But there was one question on my mind to which I found no answer. Is there any word on whether 'Fusion' will also be 'Unbreakable'?"
I spent several minutes cleaning up the coffee I had sprayed over the keyboard after reading that. I mean, "software" and "unbreakable" appearing in the same book, let alone the same sentence, is stretching credulity to its farthest limits. As the story about the Quality Assurance survey Compuware conducted shows, the idea of even trying to make software "unbreakable" is close to anathema to many companies.
Now, before Oracle’s lawyers start sharpening their pencils in anticipation, I cast not one hint of a brickbat in its direction. But let’s face it, the reputation for quality, reliability and fitness for purpose that software in general has acquired over the years still leaves much to be desired. "Unbreakable" applications remain a dream goal for mystics or the slightly deranged.
But maybe we have put up with the alternative for too long. Maybe it is time that users should expect software to be, while not "unbreakable" (that’s arguably impossible to achieve), at least pretty damned reliable and robust - in much the same way that I assume that, when I go to bed, the walls of my house will still be there in the morning.
I do have an argument with the assumption underpinning Oracle’s view of SOA and Fusion-related reliability. The fact that components have been pre-tested does not, ipso facto, mean that a composite application built from them will itself be reliable. But to be fair, as time goes by and the inter-dependencies and interoperability quirks of components get charted more comprehensively, I can see the possibility that Fusion could get at least a bit closer to the unbreakable dream. Indeed, so could every application.
As we move towards a service-based, composite-application constructed environment, the users will also move towards the presumption that the services they call up will work - and not just some of the time.
Surely, that is a more important objective for developers than coming up with yet more richness in tick-box functionality. ®
COMMENTS
Allegedly? No, it's true...
I met Praxis at a BCS seminar some time ago and was impressed by its approach - a hybrid of conventional testing methods and formal approaches. The point it made, iirc, was that it found roughly the same number of defects using testing and formal proof - but that (despite the overheads involved in learning the techniques etc) cost-per-defect-found (for the sort of defects found using proof) was much lower using the formal proof approach. OTOH, using formal methods exclusively was impractical.
The speaker also said that SPARK-ADA was a safe, restricted, subset of ADA - but if you tried to do the same with C there'd be nothing left <g>. In other words, ADA really does have advantages for writing reliable code....
Pan Pantziarka and I wrote an article on this sort of thing for Applicatiion Development Advisor back in 2002, I believe. We still own the copyright, I think, so I might see if we can resurrect it....
Allegedly...
It's already being done. There's a company called Praxis High Integrity Systems (http://www.praxis-his.com/) who (I'm told - no, I don't work for them!) create software which needs to be completely reliable (think air-traffic control systems) by applying the kinds of theoretical techniques taught in formal programming courses but rarely applied in the real world due to the extra work involved.
As far as I remember, they use a language called SPARK-ADA which is a subset of ADA, but with annotations for pre and post conditions on various blocks of code. There's then a tool which checks that the code ensures the post-condition holds if the pre-condition held when the code was run, etc.
Rather them than me, but still, nice to know someone's trying!
This has never ceased to amaze me....
It baffles me that we, the users, have been prepared to put up with "buggy" software for as long as we have. It's down to the mindset of the developer - it's more interesting to produce new stuff than to get it working.
A classic book on software testing (can't remember it's title, sorry!) had a story about a couple of hardware engineers who put together a little software program to help them with their development and testing. It became commonly used, and as far as anyone could tell, it had NO bugs. When asked how they had managed to achieve this Holy Grail, they said in a puzzled tone, "We didn't know bugs were allowed."
That's the approach developers should be taking, and should have been taking for the last thirty-five years. Bugs aren't allowed.
It's probably too late now.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
