The Software Development Process asCompared to Traditional Manufacturing

Steven C Jackson

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 traditionalmanufacturing. He states that decisions in the software development cycle are analogs of parts in amanufacturing line in that “both flow through a network, wait in queues at bottlenecks, [and] havethroughput delays”. While I believe that this broad statement can indeed apply to both processes (andwe have yet much to learn from the traditional manufacturing aspect), at a finer level I find themanufacturing 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 employspeople in similar roles – but the similarities between the two processes end there. It may be the casethat every industry has customers, business analysts, designers, workers/programmers, and testers butthe internal functions are quite different. Engineering demands an intense interaction between both thesoftware development team/company and the customer that,generally, manufacturing lacks. Endcustomers 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 specializedand requires much more intense interaction between the purchaser and provider. After receiving theinitial specification from the customer, the analysts and designers then provide a model that theworkers/engineers adhere to in order to create a product.The role difference between the engineers and workers at this stage are incomparable: workers receive arigid design that has been implemented in an assembly line process where there is no deviation fromthe standard set forth. Assembly line workers assume their same role everyday, whether it be to perhapstighten the same screw or spot-weld the same joints. Software engineers have an array of tools at theirdisposal and different ways in which to approach the problem. The difference really comes down tomanufacturing 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 arigid instruction. Developers must have constant communication among themselves in order to resolvesoftware issues that come through the need for code interoperability unlike the next person in theassembly line who only requires that the previous person passed the product down the row. This personcan be assured that the previous person turned the wrench in the correct direction and visually takecomfort in the fact that it was done properly as opposed to the developer who must generate code that isflexible yet secure enough to achieve the joint objective.Manufacturing has the luxury of having a vast history through it a rather thorough quality assurancemodel in practice that doesn't require so much adjustment after product delivery. The software failurerate over time has dramatic spikes which the developers must constantly address while trying to decidewhether to maintain the old code or create new code from scratch. Automobile companies may have toworry about recalls from time to time but software companies constantly have to address security issuesand 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 roadsand use the same gas and deliver you to the same destination in 2008 but software over even a fewyears' time period has a constantly changing architecture and need – even if if its to solve the same orsimilar problems.In the end, I do wish software development were more like traditional manufacturing and the twomodels will become much more similar. Software will always have a different process than