Tuesday, February 16, 2016

Building robust software

the logo is from somewhere else, but it's a pic! I was reading this summary of a talk that Dr. Gerard Holzmann held at USENIX Hot Topics in System Dependability mini-conf on 7 Oct 2012 in Hollywood, California. In it there is a link to what the people in the JPL decided to use as the core of the coding standard: The Power of 10. Yeah, it sounds like a self-help system for addicts, but in fact it is a very smart idea. You see, when you code for the JPL you are talking about code that you will design and test on Earth, then run in space, often years after first developed. It needs to be robust, it needs to be as safe as possible and to make easy detecting problems early on. They tried with a style coding standard, but they failed, mostly because people were not being able to follow all the rules they decided on. Here comes the brilliant idea of taking the most risk alleviating ten coding rules and make it a kind of core of their development style. A form of software ten commandments, if you will.

Some of the rules there are quite counterintuitive. You may check them in link format here and in PDF format here. I was particularly interested in rules 2 and 3: allocate everything you need before you run the program (so eliminate things like more memory allocation or garbage collection) and giving all loops an upper bound (so make sure there will never be an infinite loop). The others are either common sense or already implemented in modern programming languages.

If I were to implement this, I would try to encapsulate the idea of finite loops, so instead of foreach/for loops I would use a class with Foreach/For methods (akin to Parallel). The memory allocation thing is trickier in .NET. The idea of garbage collector is already built into the system. The third rule in P10 says "Memory allocators, such as malloc, and garbage collectors often have unpredictable behavior that can significantly impact performance". I wonder if there is any way to quantify the performance losses coming from the framework memory allocation and garbage collection. As for disabling this behavior, I doubt it is even possible. What I could do is instantiate all classes used for data storage (all data models, basically) I will ever need at some initialization stage, then eliminating any usage of new or declaring any new objects and variables of that sort. It kind of goes against the tenets of OOP (and against P10's rule number 6, BTW), but it could be interesting to experiment with.

What do you think? Anyway, feel free to ignore my post, but read the document. People at JPL are not stupid! I loved this minimalist idea they used: just reduce all coding rules to the more important ten.