Thinking Outlet

The ACM Queue article: Software Needs Seatbelts and Airbags contains a rather grim view of the state of software today.

The software industry is in a position similar to that of the automobile industry of the 1950s, delivering software with lots of horsepower and tailfins but no safety measures of any kind. Today’s software even comes complete with decorative spikes on the steering column to make sure that users will suffer if their applications crash.

I do believe we are much better at building software than claimed in this quote, in particular safety-critical software. However for more general purpose software like web-services etc., where the high development costs of safety-critical methods is not cost-effective, there is still a lot to be done to improve the quality of software in a cost-effective way.

This article discusses an interesting approach to automatically add safety to software. The article makes a distinction between a bohrbug, a “good, solid bug”, whose occurrence conditions are known and a heisenbug a bug that occurs non-deterministically, and cannot easily be replicated. This is an interesting idea, and the authors group has developed a tool DieHard that can do this automatically. Given my background in Formal-Methods I’m inclined to view this kind of an approach sceptically, as it would seem to be much better to write the software correctly in the first place. Nevertheless the tool promises to eliminate dangling pointer errors, which is definitely valuable. So I don’t see any reason why this approach should not be incorporated into software development flows.

The approach is based on adding extra padding to memory allocations, thus alleviating the effects of overflows. It would seem to me that this could allow for a cost/efficiency tradeoff, because adding more padding is going to decrease the probability of overflow errors, while increasing memory consumption of the application. I believe there is a lot of promise in this approach, as it would allow us to start talking in terms of adding a 10% safety margin to certain aspects of systems. This would be an important step in transforming software quality from a black-art into an engineering discipline.