The Model T and software

We can learn a lot from the past. Many industries have dealt with issues that seem new to the development industry, yet we can use the knowledge from older industries.

Let's apply the manufactoruing model to software. In this model, we can consider software a manufactured good, like a car or a pair of shoes.

In the mnufacturing model, you have the following costs: raw materials, facilities and equipment, manufacturing (operating the equipment and transforming the raw materials into finished product), and distribution. One could add post-sales support (since software has a lot of support), disposal of waste products, training for workers, marketing, industrial engineering and operations research, and management overhead, but let's stick to the basics.

For PC software (the kind sold on floppies or a CD), there were no raw materials, the equipment consistent of the computers and tools forthe development and testing teams, the distribution consisted of producing CDs in packages, and the post-sales support could be significant.

Web software and cloud applications have a similar model. Again, there are no raw materials and the equipment consists of computers (perhaps servers) and software. Distribution costs are lower, since you don't have to ship shiny round plastic discs to users.

In both types of application, the big costs are for development, testing, and support. Businesses recognize this, and are attempting to reduce these costs with outsourcing. It is a short-term, quick-fix solution and one that will provide little reduction in cost.

Many programs are complex. As Fred Brooks explains, software consists of essential and accidential complexity.

As an industry, we have two problems. First, we have no way to measure complexity. Second, we don't care about complexity.

The first problem is not completely true. We do have ways of measuring complexity, some better than others. All involve work and thinking, and can produce inconvenient results. But none (of which I am aware) can differentiate between the essential and the accidental aspects of complexity.

The second problem is the bigger. We accept complexity. Given deadlines and the the need to ship something -- anything, as long as it works -- we make no effort to reduce the complexity of our systems. As a result, our systems grow in complexity.

This complexity drives up cost. It is harder (read that as "more expensive") to change a complex program than a simple one.

It;s worse than that. The typical application life cycle process limits changes to those which achieve specific business needs. These processes prevent members of the team from improving areas of the code. As a result, the typical application life cycle process ensures that complex code will remain unchanged until a specific business need arises, and then (since no one knows the code) the programmers will make the minimum set of changes to satisfy the requirements (in fear of breaking some other feature).

So the system grows in complexity.

Yet the complexity of the system drives the development cost, and (I'm pretty sure) the support cost, the two costs that worry managers.

The way out requires lots of work and a change in our thinking. First, we must measure the complexity of our systems. (Or perhaps I should put as the zeroth item: we must decide that we *want* to measure the complexity of our systems and use that measurement in the management  of projects. Then we can decide on measurements.)

We have to expand our project management skills to account for complexity. We must project the complexity of solutions and include that measure in our decision to implement a specific solution. We must possibly decline some changes based on the increase in complexity (and therefore the increase in subsequent development and support costs).

Not everyone will like the analysis of complexity. Marketers will be unhappy that their latest request was denied based on future costs. Developers may feel that they are rated on the quality (and complexity) of the code they write. Managers will see another task in their (already overflowing) inbox.

Yet measuring and managing complexity is the only way to tame the software monster. Without the proper discipline, our systems will become large and expensive to maintain. More expensive than the next company's system, perhaps.