Industrial Strength Software
Googling the term Industrial Strength brings up a surprisingly high number of entries in the technology sector, with contexts ranging from development languages to operating systems to frameworks, even to a company that uses the term in its appellation. I had expected far fewer technology entries, with more pertaining to things like oven cleaners or aluminum foil. The difference is probably due to the internet being within the technological universe – I don’t recall surfing the web the last time I needed to clean the oven (though my wife would probably suggest the internet wasn’t around the last time I cleaned the oven…).
Just as for commercial products, the term Industrial Strength in tech circles appears to have become a sales cliché rather than a trustworthy indicator of a solid product – one could almost expect a little trademark symbol after the phrase. What could Industrial Strength really mean for software and the process used to develop it?
A less abused phrase that seems to work well is Fitness for Use. A product that is fit for use for the end user is one that allows them to achieve their intended goals effectively and efficiently. For a software product, this conjures many of the quality attributes that are largely ignored in software projects, such as reliability, security and usability. It also suggests little bloat, which in software can range from unnecessary features to distracting multimedia to Easter eggs containing the names of the development team. In most applications, save those in the entertainment field, a program to drastically reduce these software carbohydrates could save time, resources and risk, and make the application more likely to meet the end user’s needs.
A software product needs to be fit for use for the internal development team as well. It is a rare application that is not revisited after it is first released, so software (code and surrounding artifacts) should be developed with the expectation that it will be consumed many times after it is first created. Readable, consistently developed code, lucid designs that have been developed to support an efficient code base, all of which has been thoroughly exercised and based on end-user validated specifications that support a goal to achieve a stated vision. All of this, commonly understood and managed throughout the lifecycle from inception to retirement, makes for an internally fit for use product. How many of us have had to struggle through arcane code to figure out how something worked, because the reams of documentation didn’t match the code? It’s not the size of product and documentation that matters; it’s whether it can actually be used to achieve a goal.
Fitness for Use is a term that applies to the development process as well. An Industrial Strength process is not one embodied in binders of documentation, but is one that supports the development of software that is fit for use for by the developers and end users. Policy and procedures are rarely read or understood in the trenches. While they make great fodder for assessors who seek objective evidence of a high maturity process in place, they are not the critical elements that facilitate the creation of great software. More often than not, they camouflage a chaotic development environment that still relies on heroic efforts to get the job done. A strong process will contain a very limited number of critical checkpoints to ensure that the right things are being done, and will be supported by a range of checklists, guidelines, forms and tools that facilitate the effective development of strong software. A fit for use process facilitates more often than mandates, informs rather than bewilders. It is necessary and sufficient to get the job done, and quality attributes such as maintainability, usability, and reusability can be realistically applied to the process as well as the product.
The only problem with Industrial Strength Software is that it rarely exists today outside of the sales clichés. Most is not fit for use for the end-users or the development team, from the perspective of the product itself or the process used to create it. Indeed, in many cases, what we have is bloat – too many features, too much outdated documentation, too much process pomp and circumstance. More is not better, what we need is the right amount of product, done in the right way – we need balance for truly Industrial Strength Software. – JB