This post is inspired by a post from C. Titus Brown, where Titus asked “What do you think about the term & practice of ‘hardening software’?” and a few of us used comments to discuss the concept.
What is hardening?
As I wrote, when I worked at NASA JPL on the Remote Exploration and Experimentation (REE) Project, we used “hardening” to mean taking code, often built by grad students and sometime faculty, that worked well enough to prove a point or demonstrate a capability, and “strengthening” or improving it, by doing at least one of many things: more testing (and then fixing the discovered bugs), more documentation, better user interface, performance optimization, and/or a complete rewrite in a different language (for future maintainability).
A concept that we used and that might be useful here is the Technology Readiness Level (TRL). This says that the readiness of a technology ranges from 1, when the basic principles behind a potential technology have observed and recorded, to 9, when the technology has been successfully implemented and proven in a system used in a mission. The original discussion of this idea, then applied to hardware, took place from the mid 1970s to the late 1980s, and it has since been further developed and used by other agencies.
As part of this further development, the idea of TRLs was applied to software at NASA in the 2000s; the current NASA definitions include both hardware and software. A key part of the definitions is that the TRLs are tied to an environment in which they will be used, at least starting at TRL 4.
I believe that hardening software is part of the process of advancing a software technology up the TRL scale.
Is hardening associated with security?
A number of the comments to Titus’s blog focused on the fact that hardening is often thought of as related to improved security, particularly by those who work in security or systems. In fact, this definition is currently in Wikipedia: “…hardening is usually the process of securing a system…”
I personally think that what’s happened here is that hardening is a general term, and people tend to focus on the aspects of hardening that seem most relevant to them.
What about sustainability?
One interesting topic that is somewhat hidden in Titus’s original post is how hardening software and making software sustainable are related. By sustainable, I mean having the capacity to endure. In my opinion, sustainability for software means that the software will continue to be available in the future, on new platforms, meeting new needs.
The “definition” Titus provided from the NIH Extended Development, Hardening and Dissemination of Technologies in Biomedical Computing, Informatics and Big Data Science (R01) funding opportunity, is more related what I think of as sustainability, rather than hardening.
First, contemporary software must be easy to modify and extend, and must be fully documented. Users who experience problems with software should be able to correct the problem with minimal effort and a mechanism must exist for incorporating these corrections into the software. As the needs of a community of users change, the software that supports their research efforts must be adaptable as well. The ability of software to be repaired and to evolve is particularly important because the scientific discovery process is open-ended and ever-changing.
There is some overlap between the hardening and sustainability terms, but I mostly think of hardening as making the code more useful in more situations in the short term, and sustainability as making the code more likely to be useful in the long term. (I know the rewriting I mentioned in hardening is a long term issue, but I said “mostly”…)
If we look back at the NASA TRL definitions, sustainability is only found in the last of these for software, TRL 9, which includes “sustaining software engineering support is in place.” However, it is not mentioned for hardware.
Another way of looking at this is that hardening is improving how software meets a set of functional requirements, while sustainability is one or more non-function software requirements, as proposed by Penzenstadler et al. (Note that I disagree with Penzenstadler when she considers security a non-functional requirement.)
A final point that might illustrate this difference is in the language used. I am comfortable talking about “hardening software” as a general practice, but I feel that I should say “making software sustainable” rather than “sustaining software”, as the sustainability of software can only be proven in retrospect, while hardening is a forward-looking activity.
Disclaimer
Some work by the author was supported by the National Science Foundation (NSF) while working at the Foundation; any opinion, finding, and conclusions or recommendations expressed in this material are those of the author and do not necessarily reflect the views of the NSF.
Daniel S. Katz's blog 