The software development process for a large midwestern manufacturing firm is likely to be much less efficient than that of a fresh young startup in the Silicone Valley. Many of these large firms have been around for years, and their processes were likely developed prior to the digital revolution. According to Lehman’s third law on self regulation, iterations of a software package will take on a uniform set of characteristics over time; this is true for business processes as well, since firms will tend to keep doing what has made them successful in the past. Unfortunately, applying industrial revolution era practices to digital revolution era technologies yields less than optimal results. However, with an open mind and an able guide, it is possible for these established firms to implement an efficient, modern software development strategy.
When erecting a new factory or developing a new product, established firms tend to take a linear approach. This makes sense. It would not be wise to get machines on site before the factory is built, nor would it make sense to build a factory which is too small for all the requisite machines. With software, on the other hand, the product is less constrained by similar factors. Software can be shipped with a limited set of core features that immediately provide benefits to the customers. New features can subsequently be added to software without requiring an addition to the factory. Also, unlike traditional products, software is unique and intangible. Due to these realities, it makes much more sense to develop in iterations. Following an iterative or prototype/spiral model allows for the software to flexibly change as the stakeholders’ understanding of the product evolves, and it also allows for incremental verification and validation. Relying on evolution in this way creates a more fit product in the long run. For these reasons, a traditional manufacturing firm should switch from the familiar waterfall method to a more agile approach for developing software. An agile approach gets the software into the hands of its users faster while producing a higher quality product.
Mature manufacturing companies normally have defined processes for document control, this is required to obtain the various types of quality certifications. However, their document control processes are often based upon a process that were defined when paper documents were the norm. This pattern also often spills over into firms’ software development processes. Specifications are written as electronic documents and versions of the document are stored as if they were paper. Without exception, all software development should be performed under version control; this rule should be extended to all software development artifacts. Unfortunately, many large firms create their artifacts using software which was designed for writing memos or tracking tabular data, and these formats suppress the power of modern version control systems. Not only should software development artifacts be kept under revision control, but they should also be kept in the simplest possible form (e.g. text files using the Markdown syntax). Software development teams should spend as much of their time as possible creating valuable products; they should minimize the amount of time that it takes them to maintain the necessary ancillary artifacts. Furthermore, established manufacturing firms should embrace the extensive tracking provided by revision control systems and shun traditional “paper trail” processes.
Finally, traditional manufacturing businesses need to learn to depreciate software as they would any other capital investment. Even the best made machines eventually wear out, and so do applications. It becomes obvious that a machine is nearing the end of its useful life when incrementally more money must be spent on maintenance; managers will compare the replacement cost to the ongoing maintenance costs and determine when it is appropriate to buy a new machine. Increased maintenance costs for software are not always seen, especially when development is done in-house. Managers may incorrectly view repairs as improvements, or the two may become commingled. To reduce the confusion in this regard, firms should classify their software according to its life stage. High expenditures on a software which is in the evolution phase should be accepted, while increased expenditures on software in the servicing phase should be a warning sign.
With these three major changes, an established company should be able to refactor its software development processes to provide better products faster. They may even be able to profitably apply some of these practices to their main line business.
Christopher
