The Software Development Process as Compared to Traditional Manufacturing

In the STSC CrossTalk article What Engineering Has in Common With Manufacturing and Why It Matters, Dr. Alistair Cockburn explains that software engineering has common threads with traditional manufacturing. He states that decisions in the software development cycle are analogs of parts in a manufacturing line in that “both flow through a network, wait in queues at bottlenecks, [and] have throughput delays”. While I believe that this broad statement can indeed apply to both processes (and we have yet much to learn from the traditional manufacturing aspect), at a finer level I find the manufacturing of goods is currently dissimilar to the development of software.

I agree with Dr. Cockburn on a high level – that both manufacturing and software development employs people in similar roles – but the similarities between the two processes end there.

It may be the case that every industry has customers, business analysts, designers, workers/programmers, and testers but the internal functions are quite different. Engineering demands an intense interaction between both the software development team/company and the customer that,generally, manufacturing lacks. End customers in the industrial sector often have little decision-making power (outside of focus groups) whereas software customers are critical in defining the output. Software is generally very specialized and requires much more intense interaction between the purchaser and provider. After receiving the initial specification from the customer, the analysts and designers then provide a model that the workers/engineers adhere to in order to create a product.

The role difference between the engineers and workers at this stage are incomparable: workers receive a rigid design that has been implemented in an assembly line process where there is no deviation from the standard set forth. Assembly line workers assume their same role everyday, whether it be to perhaps tighten the same screw or spot-weld the same joints. Software engineers have an array of tools at their disposal and different ways in which to approach the problem. The difference really comes down to manufacturing employees who repeat the exact task whereas the developer tasks are moving targets. The developer largely depends on style and a more organic interaction between coworkers rather than a rigid instruction. Developers must have constant communication among themselves in order to resolve software issues that come through the need for code interoperability unlike the next person in the assembly line who only requires that the previous person passed the product down the row. This person can be assured that the previous person turned the wrench in the correct direction and visually take comfort in the fact that it was done properly as opposed to the developer who must generate code that is flexible yet secure enough to achieve the joint objective.

Manufacturing has the luxury of having a vast history through it a rather thorough quality assurance model in practice that doesn't require so much adjustment after product delivery. The software failure rate over time has dramatic spikes which the developers must constantly address while trying to decide whether to maintain the old code or create new code from scratch. Automobile companies may have to worry about recalls from time to time but software companies constantly have to address security issues and compatibility problems while combating time and requirements that degrade the effectiveness of the software. A simple comparison is that an car manufactured in 1980 can still drive on the same roads and use the same gas and deliver you to the same destination in 2008 but software over even a few years' time period has a constantly changing architecture and need – even if if its to solve the same or similar problems.

In the end, I do wish software development were more like traditional manufacturing and the two models will become much more similar. Software will always have a different process than manufacturing because it is an intellectual process (as opposed to physical) that depends on the individual writing the component but computer scientists can adapt much of the manufacturing process. I envy the structure and standards that are integral to the traditional manufacturing process. Software development is maturing more throughout each decade and I hope that we have a post-industrial revolution that enables us to adopt development standards for production of mass-market software. Currently, there appears to be a bit of move in that direction in the software development with open products like GNU/Linux and Drupal where a standard core is created, around which programmers are encouraged to hook modules. There will always be a desire for specialized software as much as there is for customized manufactured goods but this article, as much as I disagree with the current comparison, encourages me to hope for and help lead our way into a manner of development that is analogous to traditional manufacturing.

References

1 . Cockburn, Alistair (2007). What Engineering Has in Common with Manufacturing and Why It Matters. In STSC CrossTalk. Retrieved September 11, 2008, from http://science.kennesaw.edu/~hhaddad/Fall2008/CS8431/What%20Engineering%...

2 . Pressman, Roger S. (2005). Software Engineering: A Practitioner's Approach. New York: McGraw-Hill

-----------------------
Steven Jackson is currently a student in the Masters of Science in Applied Computer Science program at Kennesaw State University