Tag - software engineering

Entries feed - Comments feed

Last entries

Tue 02 Feb 2016

"Software Aging"

In 1994, David L. Parnas published a provocative paper called "Software Aging". I recently read this paper and found it remarkably accurate!

Software is digital, so how could it age? Parnas identified two different causes for software getting "older" when time passes:

  • "Lack of Movement", i.e. the inability for the software to match evolving user or environment expectations. A computer environment evolves constantly; language and compiler changes, operating system and library changes. But this is also true for user expectations: in the 70' people expected a text interface, in the 90' a graphical interface and now they want a web interface accessible from any device or an App usable on their mobile devices;
  • "Ignorant Surgery", i.e. the inability to correctly adapt the software as time passes. When somebody modifies the software, probably not the original developer(s), she/he won't probably understand its design and probably modify it as she/he understand the software. At this point understanding the software means understanding the original design as well as the introduced new design. After several of such modifications, nobody can understand the software and in some cases it should be rewritten from scratch.

Although this idea of Software Aging was proposed 22 years ago (and appeared 47 years ago, the famous "Software Crisis", according to Parnas), it is striking to see that it is still true. When I see it takes nearly one year to make a new release of the Debian system, I view it at software aging at work: the environment evolves in unexpected ways and each software should be adapted to match its new environment. And sometimes, applying those changes can be very difficult and lead to Ignorant Surgery, like the famous Debian OpenSSL bug.

How to avoid this software decay? Parnas gives some advises, I just summarizes them here:

  1. Design for change, i.e. apply usual Software Engineering principles like Information Hiding, abstraction, separation of concerns, proper use of object orientation, etc.
  2. Document! Document your design, your choices and document for the people who'll come after you work on the software.
  3. Review! Review the design, code or other software artifacts by other members of your team, by experts in the domain on which your software is applying, etc.

Even for actual software, above principles can be applied, retro-actively. Parnas gives some advises.

All current software are aging. Hopefully, 22 years ago, Parnas gave some very good advises on how to develop and maintain software to limit this phenomenon. Listen to him, apply them.

Tue 17 Dec 2013

Book review: Better Embedded System Software

better_embedded_system_software_cover.gif Better Embedded System Software is a very good book if you write software, and not only embedded software!

I discover this book when following the Toyota Unintended Acceleration case where Philip Koopman, the author of this book, was a plaintiff's expert. Philip Koopman is an Associate Professor at the Carnegie Mellon University.

Why is this book so good? Because it explains in daily words what should be the ideal software development process. And not only it details the ideal process, but it gives concrete, down to earth advices on how to improve your current process and software development habits.

The book is divided into 30 small chapters, following the order of the usual V cycle (overall process, requirements and architecture, design, implementation, verification and validation, critical system properties). The chapters are very short, about 10 pages, and relatively independent. This one of the great point of the book: it is easy to read a chapter, there is not need to allocate a long time slot for it. You can pick the chapter that is most interesting to you. And as the chapters are right to the point, you immediately get useful advices and you can immediately start to apply them on your own development.

The other great quality of this book is that the author has a strong background in embedded software development. Therefore the advices are realistic and graduated. The author knows that you are going to find barriers and limitations in your work environment and he helps against them. For example, there are two chapters on producing some documentation but not too much. Even if you cannot apply the whole set of advices, you nonetheless get some ideas on own to improve your current software and what could be done in later steps.

I am not an expert on all the topics presented in this book (that's why I bought it!) but for the domains I knew (e.g. concurrent programming), the advices seem balanced and appropriate.

Of course, 10 pages for a chapter is very short and some subjects are so wide that they would deserve a book on their own (e.g. safety and security). In that case, Koopman's book give useful pointers to continue your reading and the summary he gives is an excellent introduction to the topic.

As I said many times, we are currently making very bad software and we should improve this situation. Better Embedded System Software is the one the very few books that you should keep close to your table and consult on a regular basis.

If you cannot afford the book, some quite detailed slides on Avoiding the 43 Top software risks have been made available by Philip Koopman.