Recommended reading (it’s short), from the January 2010 issue of CACM:
What Should We Teach New Software Developers? Why?
by Bjarne Stroustrup
It’s a wonderfully accurate and concise summary of the disconnect between the ivory tower and the trenches – i.e., (some) computer science academics and (some) software development industry managers, with commentary on other topics like why or why not to regulate the software development industry.
My favorite part is this from the conclusion (emphasis added):
We must do better. Until we do, our infrastructure will continue to creak, bloat, and soak up resources. Eventually, some part will break in some unpredictable and disastrous way (think of Internet routing, online banking, electronic voting, and control of the electric power grid). …
Bjarne isn’t prone to disaster warnings (indeed, this is the first time I recall seeing a comment like this from him, even over a beer or three), but he’s right. This hits directly on an issue I’ve also been giving thought to in recent years: As an industry and a society, we routinely underestimate the degree to which we’ve gradually allowed our automated civilization to become reliant on computers and software, and vulnerable as a result. We’ve been satisfied with making any given system “reliable enough” for the intended application (e.g., having a much higher bar for life-critical software than for a word processor), and so far we’ve been able to get away with that without the level of broad regulation for software development that is routinely required for other disciplines like engineering that are involved in providing essential products and services. Of course, as Bjarne points out, one reason for the lack of regulation of the software development industry is that we don’t know (and/or can’t agree on) exactly what to require and how to measure it; we’re just not as mature a field yet as civil or mechanical engineering.
Recognizing the potential scope of a catastrophic and systemic software failure in the field – one that disables a vital piece of infrastructure (say, electric power or food distribution, country-wide for a month) and that can’t be patched with a remote update – adds impetus to understanding and solving the kinds of issues Bjarne writes about.
Sutter’s Mill 
Of course the underlying problem is that increasingly the world does not value quality in any human endeavour. As has been discussed recently in the media and on the web, public companies are required *by law* to ‘increase shareholder value’ above all else, which quite apart from things like the destruction of workers rights and the jetisoning of any notion of value for the customer, ultimately means that the business goes under due to an exclusive focus on short term gain, with no long term investment.
It’s true that software in particular has a culture of crufty hacks, but the problem is much wider.
I entirely agree with Mm. Software out there is good enough. The fact that we’d like it to be better is noble, but until someone wants to pay for better, the software will continue to be good enough. Good enough, taking price of software into account, means optimal. Certifications already exist, such as e.g. IEEE CSDP (ISO/IEC 24773) and a plethora of vendor-specific ones. Business that does not take care of its customers ultimately fails. Those economic entities that deem certifications necessary for their business, already require them because market requires it from them. Certifications emerge because of market demand, without governmental regulation promoting politically-favored monopolies and strangling economic competition.
Effort on the teaching side is absolutely welcome and desirable. Strangling software market with governmental regulation will be detrimental to software quality.
link correction (removed ‘)’ from link):
http://www.se.rit.edu/
All too true, though it’s not a completely uncharted field. Individual pockets of industry do have regulation, and have had for some time. The industry has a lot of headroom to improve, but outside of consumer software where most of us developers earn our keep, best practice is more refined than many might realize.
The book “Safeware” (Nancy Leveson) is a great introduction to software safety, but probably dated by now. Steve McConnel was looking at the notion of professional software engineering back when I was in college 10 years ago in “After the Gold Rush”, and more recently “Professional Software Development”. _Systems_ engeering principles are also applied in more rigorous development environments (DoD, NASA, etc.) and modern systems engineering research & education have an increased focus on software’s role in complex systems.
I’ve long felt we need to start training most software developers more like engineers than scientists, but then again I might be biased (alum of http://www.se.rit.edu/).
I strongly agree with most of what Bjarne discussed. It’s not about the programming language or technology a team uses, however. I believe it’s implementing common standards and best practices in software development that must be taught at university level.
In my experience as a software developer (not a programmer or code-monkey), in most organizations, well established tools and proper guidelines are not followed. Most projects are just code-as-you-go, with no proper workflow being followed (be that RUP or Agile). This leads to bad software that is hard to maintain, and a pain to refactor. And most of these developers do not take pride in their craft, satisfied to hack out code that “just works”.
If we put more emphasis in software development classes that teach how to write elegant code, how to use design patterns, and how to tackle design and functional requirements before even hitting the keyboards, then I believe we are on the right track.
First, it should be users (clients) who decide the reliability level they want.. and they are already doing that.
Reliability has a price, you can’t pretend a nuclear station management software has the same price of a text editor, and the complexity is only part of the figure.. security/reliability is a big part of it.
So to get reliability you have to sacrifice innovation, performance, time to market, and money.
Probably we could have perfectly secure operative systems by now.. if we only stuck with cli, single tasking and fully interpreted languages -> this is not what customers want.
Beside, if you target security and reliability over all, probably C++ is the last language you want to consider, because it is designed to trade off simplicity and reliability over performance and low level control – almost any other language is better in that sense. The fact itself that we are using C++ in so many fields, is testimony to the fact that *absolute* reliability is not a primary user requirement, special cases excluded.
That will happen about as soon as we get a universal scientific theory of everything, and be about as useless if it does happen.
The only change needed is to realize any system will always break or be subverted eventually, which is why things like internet voting are completely impossible to implement in a safe manner. Even if you don’t use ms access as your backbone like diehard..
It would all be a whole lot easier if we used simpler, more high-level languages. In other words not C/C++. We should be following Wirth and not Stroustrup (sorry Bjarne!)
Of course, if you write software for any of the already regulated industries (medical, aerospace, etc), there are already existing regulations on the software written for these fields. I don’t know enough about the regulations to say how well they work, but the lessons learned from these fields could be applied to other less regulated industries.
There are also industry coding standards to avoid common problems, like MISRA-C for the auto industry.
I vote against. To keep everything regulated we need someone who will watch over things and make sure everything is done within regulations. This will soak up more resources eventually than occasional critical failure once in 20 years.