Onslaught of functionality

Beginning of September I attended SafeCOMP 2009 in Hamburg to hold a talk on the challenges of object oriented programming languages in safety critical applications. One major point which was driven home again and again was that object oriented programming can certainly be used in safety-critical areas but it needs strict development rules which need to be followed rigorously. The topic by itself – software development in safety relevant applications – is incredibly complex. Just look at the DO-178B certification standard: its successor, the DO-178C has been under inspection and development for quite a while now. One of the biggest obstacles to overcome is, that changes and additions to the standard need to be done unanimously. Since there are so many interested parties involved in the standard’s development (anyone who wants to participate may do so, no particular prerequisite is required), it takes a lot of time to resolve discussions.

Any kind of software development team may learn a good deal from safety-related coding guidelines and recommendations, simply because it also has impacts in regards to stability, security, reliability and last but not least maintainability. One of the primary issues of object oriented technology in regards to safety is dead and deactivated (unused by “design”) code. For instance, when you think about complex software packages like JBoss 5, not many applications can say of themselves that they are truly using 100 percent of the functionality offering of its middleware framework. The thing is, that the more additional features there are – no matter if they are used or not – they can produce unexpected errors and problems.

A very good example is outlined in TWIT’s Security Now podcast episode 211. Developing “single-use” appliances with a Windows machine or a general PC underneath opens up so many potential attack routes that they are hard to manage and can barely be called secure or trustworthy to begin with. Every additional program or functionality stone you heap upon that pile of preexisting “conditions” aggravates the problem one or more degrees. For instance, just today I read about security attacks made possible due to lack of maintenance and security awareness. There are so many nobs you can turn in a Linux system, it can be overwhelming for some people. The result is insecure systems because people weren’t even aware of the potential risks and problems.

However, it’s not just the frameworks we are using, it’s also very much about the programming language we choose. While C++ will treat the programmer like a consenting adult, Pascal will treat her like a child and Ada like a criminal. C++ is a complex and powerful language, but this power can be misguided. We all know there are people who live the “it was hard to code, it should be hard to read” approach, but even if you try to write legible C++ code it happens quite often that a few lines of code can have ambiguous meaning. A misplaced bracket can wreak havoc, literally.

I worked on Flash- and Flex-based interactive kiosk-applications myself which were then deployed on Windows and Mac OS. Did it work? Sure it did. Were there safer alternatives? For sure, however sometimes time and budget constraints require you to choose a technology which has already many of the required functionality built-in. Even though this comes with additional, unnecessary functionality, it permits you to boost your development cycle and produce stable and good applications if done properly. I won’t recommend it for building an airplane navigation system but for a simple kiosk app it is certainly a good thing. This kind of trade-off between using preexisting packages, frameworks and libraries and avoiding dead and deactivated code by building your own specialized niche product will always be looming over IT.

I guess the point of this post is, that when doing software development, very much like running your own servers and applications, it is important to keep safety, security, reliability and maintainability in mind. To exaggerate the point a little: noone wants to crash in his car, because he changed the radio station…

Further references

You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

Comments are closed.