Comments on Stroustrup's paper, "Software Development for Infrastructure" in IEEE Computer, Jan. 2012

Last Updated on April 16th 2012

This post has my comments on an academic paper (article), "Software Development for Infrastructure" in IEEE Computer, Jan. 2012, by Prof. Bjarne Stroustrup, Inventor of C++, Distinguished Professor & holder of College of Engineering Chair in Computer Science at Texas A&M University, ACM fellow as well as an IEEE fellow.

The comments are provided as separate bullets. For copyright reasons I cannot use too many quotes from the paper and so have tried to provide minimal context by paraphrasing. Reading the comments without reading the paper side-by-side may make it a rather "disconnected reading experience" :).

• This paper starts with some serious concerns about how "Our lives are directly affected by software correctness and efficiency". It argues for the urgent need for improving the reliability levels of "Infrastructure Software".

• I entirely agree that infrastructure software has far higher correctness, reliability, efficiency and maintainability requirements that non infrastructure apps. I further agree that education curricula for infrastructure developers should be different from that of application developers. I also very much like the term infrastructure developer (development).

• It was quite a revelation to me that Google used over 2 million MW power in 2010 ro run its servers. My God! That's a huge amount of power.

• The fact that industrialized society worldwide is heavily dependent on systems which can hurt people physically or economically has been well expressed. It seems to be so very true and so very SCARY.

• There is a huge amount of non infrastructure software (apps) where the tolerance for bugs is far higher. This high tolerance for bugs gives more room for creative software developers who are strong in creativity and ideas and who may not necessarily need very high levels of engineering discipline.

• "I call software where failure can cause serious injury or serious economic disruption infrastructure software." I very much like the simplicity of this definition. The guy-on-the-street can understand this definition.

• "One of my inspirations for quality infrastructure software is the requirement AT&T placed on switches in its telecommunication system backbone: no more than two hours of downtime in 40 years" Ravi: I am lost in ADMIRATION! Hats Off! No wonder AT&T achieved such a FANTASTIC QUALITY reputation.

• I agree that infrastructure software developers should be very serious about reliability. But will the market economic realities accept this argument? Or do we need some regulators like banking regulators to enforce this?

• I felt the author stretched it a little too far when he wrote that but for computerized systems, most of us (industrialized world is what he meant, I guess) would starve. To me, this is quite a statement. Is it really TRUE? Now, I have lived for nearly a decade in a very rural (outback) town but which is an international spiritual centre in India. So our small town is surrounded by pretty rustic villages. Initially I thought our setup is geared to manage life without computers or internet. But then I had a second thought :). I use internet banking to avoid spending time queuing up in the local bank. The local bank itself is HEAVILY COMPUTERISED and network dependent - I mean it uses online systems with centralized databases. The railway reservation counter is also similar. So, I guess, even in my small town a catastrophic internet/network failure will bring banking and railway reservation systems down (railway is the lifeline of lower middle class & the poor in India i.e. the vast majority). Maybe we will not starve as the villages around grow food. But we certainly will take a hit in the MATERIAL QUALITY of LIFE.

• An update on my comments: I would like to withdraw the comment about me feeling that the author had stretched it a little too far when he wrote that but for computerized systems, most of us would starve. In a private mail exchange with one of the leading lights of the software world who seems to have deeply analyzed the extent of computerization in almost every aspect of modern life, he put out a strong case justifying the above 'starve' comment. As I am kind-of out of touch with modern heavily industrialized life I realize that I am not in a position to really comment on the 'starve' point. I think the accurate and truthful thing for me to say is that I am not knowledgeable enough about the extent of computerization in modern life to comment. Prof. Stroustrup may be right. But let me additionally add a prayer to Almighty God that we software chaps succeed in putting our "infrastructure software" house in professional engineering order so that such calamities do not happen.
  

• I did not realize the relation between software efficiency and energy conservation. Fascinating point given the nearly desperate state of affairs in the energy sector hurting both developed and developing countries. And who knows how long the oil is going to last! After Fukushima, even in rural India, nobody wants a nuclear power station in their backyard (http://en.wikipedia.org/wiki/Koodankulam_Nuclear_Power_Plant).

• As a former systems programmer (but not a computer language designer/creator) I find the suggestion of using a systematic and structured programming approach involving type-rich programming, for infrastructure code, sensible. It is more cumbersome perhaps for the programmer but pays back in terms of the type-checking and type-safety that the compiler does for him and thereby reduces bugs. I think it would be a fair decision if one imposed such type-rich programming language & programming conventions/style for infrastructure code.

• I buy the argument of designing for compactness and predictable access patterns for infrastructure code. I don't buy it for apps. code that run on a smart phone. Yes, it will drain more power but does that get offset by the benefit it provides to the smartphone user? Perhaps it does. Perhaps one can take a proper call on it only if one knows about the extent of power hit due to a particular app. that is not designed for compactness and predictable access patterns.

• I had not thought through or realized that class objects being allocated in dynamic memory results in an efficiency downside due to non-compact representation. But I did have the general impression that efficiency is typically better for C/C++ programs as compared to Java (or Python).

• For me a "design error" for systems programing (e.g. an automation tool controller software) would be more in the realm of the Object Oriented Analysis & Design of the system, but also possible in the area of code, of course. Though I may refer to it (in code) more as an algorithm flaw rather than a design flaw.

• I feel that if the program did deal heavily with heights and widths of rectangle objects it would be fine to have a Rectangle(Point(100,200), Height 100, Width 50)); constructor too with Height and Width typedef'ed to int (or unsigned int).

• For infrastructure code, usage of static type-safety features must be mandatory as it can eliminate quite a few errors. And it is far simpler than designing for compactness and predictable access patterns.

• I have found C++ especially with its fantastic STL to be far superior to 'C' for writing (more) efficient and robust (reliable) code. My own string 'C' functions will typically not match STL string class functions easily let alone functions of STL vector or map classes. However I have not done any comparative measures of efficiency as that was not required in my work environment. It was easy to convince a knowledgeable senior techie about it and did not need an efficiency comparison metric. I would also like to state here that when I had to teach C++, around maybe 5 to 6 years ago, I changed the course from its earlier structure to ensure that STL classes like string, vector etc. get taught well before we come to creating our own classes. I introduced one assignment where I asked the students (who had learned 'C' in an earlier course) to do a word collection building (from file) program first in 'C' and then in C++ using string and vector. This assignment very successfully drove home to the students how much more easier it was to program in C++ using string and vector and how much more reliable and efficient it was as compared to their 'C' program solution. I taught this course for around 3 years and then this same course structure is being used by the teacher who took over from me and is currently teaching it.

• But the impression that I have is that for very heavily used code like OS Kernel code writing it in 'C' allows for easier and more visible control of overhead costs of function calls (inline does it but sometimes a programmer misses its significance). And avoids RTTI and virtual function call costs. So, even though I am not a kernel programmer or even a serious student of kernel programming, I am not surprised by Linux kernel developers choosing to stick to 'C'.

• I fully agree that "duck typing" should be avoided in infrastructure code.

• The obscure reporting of template errors puts off C++ students in a big way. I had to take very special care to give students the courage to not get thrown into confusion by string template compilation errors that they would see when they were writing their first C++ programs using the string (template) class. I think this may be a reason why, I would not be surprised if, even today, in many colleges and universities in India, C++ is taught with the STL part being a kind of optional add on at the end of the course. The teachers themselves may be finding templates tough to handle due to the really scarily long and completely obscure compilation error messages.

• In my exposure to education of or selection of systems programmers I too have found that the system does not actively encourage teaching of or spotting the ability to deliver general, elegant and simple solutions.

• I am not so sure about too many managers and too many programmers encouraging complicated solutions assumed to be efficient. At least, in my experience of the system software world (late 80's & 90s), especially where there was a system of design and code reviews, general, elegant and simple solutions were given appropriate appreciation. However, not enough was done to ensure that all or most programmers would do general, elegant and simple solutions. I mean, it was not enforced.

• Enjoyed the Alan Perlis lollipop quote :). Ha, ha!

• Code generation tools or systems driven by huge amount of option settings are almost magical! I had some exposure to this in a mini-project oriented course I taught nearly a year back where I got exposure to Joomla, Moodle, Al Fresco etc. The "exactly how it works" level certainly goes down. But from a "mix and match customizer" kind-of app. developer viewpoint I found it is okay. I mean, it is like how I use gmail and the Internet facility from my small rural outback town in India. Sometimes it is not accessible and I live with it. To protect myself from my gmail a/c data getting lost (due to hacking, say) I have my Outlook Express backup of mails. This works out decently. Similar is the case of my blogs (blogger & wordpress). Settings all over the place. Sometimes I can't get my blog show my posts the exact way I want it. But I live with what I can manage. And it has satisfied my needs overall, very, very well. So for the App space a Joomla type of development environment which heavily uses option settings and, more importantly, a bewildering array of components (many being user supplied), seems to be quite acceptable to its more tolerant of errors & outages user community.

• Fully agree that for "infrastructure code" it is vital to clean up our code.

• Absolutely agree that an education/training for applications cannot create a reliable infrastructure component developer. It can be a disaster if such inappropriately trained persons are used for infrastructure component tasks! But some persons can be very capable but "self-taught" infrastructure component developers too. Self-taught "infrastructure developer aspirants" should prove their mettle via appropriate tests. We should not exclude the self-taught community as experience has taught us that many very capable and productive "infrastructure developers" are self-taught. But, I repeat, they should prove their mettle/knowledge of infrastructure software development techniques via appropriate tests/proven credentials (e.g. software developed by them which is assessed by experts whether it proves them to be good enough infrastructure developers).

• It is VITAL to specialize our computer science, software engineering and IT curricula. In fact, I will argue for separate curricula for "infrastructure developer" and "app. developer". There may be some limited overlap but they should be two separate curricula.

• I am not sure about the mathematical basis of all infrastructure developers needing to be strengthened. Of course, a strong mathematical basis may be ESSENTIAL for infrastructure developers who FOCUS on efficiency. But a lot of infrastructure work could be done which is reliable as well as efficient using efficiency measuring techniques & tools which have been well defined by others (the ones who FOCUS on efficiency). I think I got by doing a lot of fairly decent systems software work without having a STRONG mathematical or statistical basis. But then I only used STL - I did not have to design an STL class like vector and prove its efficiency.

• I agree entirely that algorithms, data structures ... must remain core subjects for infrastructure developer (systems software) education. In fact, in my self-taught journey into systems software these were the topics that I had to study rather well. Though I must also state here that I did not have to get into in-depth Design and Analysis of Algorithms as I did not have to write libraries like STL. If I had to do that I am sure I would have studied and tried to master an Aho-Ullman or similar book on Algorithms.

----------

Some frank comments from a TOP LEVEL MANAGEMENT/ADMINISTRATION view. The paper started off with a very top level view of the need to improve software infrastructure code and the dangers if we don't. Then it delved into language details - which is important, for sure. But then this is just an academic paper. Some people may read it and change somewhat; some may continue with their old ways but most "infrastructure developers" may not even know of the paper's existence.

WHAT WE NEED IS AN "INFRASTRUCTURE SOFTWARE REGULATOR". USA is THE leader in infrastructure software. Top iconic figures of US software academia and industry should suggest an infrastructure regulator organization which lays down guidelines for infrastructure software development companies, and then conducts "infrastructure quality audits" which, if passed, grants an "infrastructure quality" stamp for the software. That may not solve all problems right away but will be a great way to start doing something about bringing a mature engineering discipline to the "infrastructure software" industry similar to, say, the civil engineering industry. If such a suggestion comes from top iconic figures then people in powerful decision making bodies may sit up and take notice.