Manufacturing vs Software Development [closed]

Question

It's often said that the software industry is immature compared to manufacturing. Specifically with regard to being process driven.

Question: Can we as developers learn from the processes of the manufacturing industry? Can adopting their processes increase the success rate of software development?

My take: In manufacturing the creation of a product is heavily process driven. You may have a factory where each person has a specific set of tasks they follow. A worker (or robot) may tighten a screw all day long. Then the next task in the process is performed by the next specialist. The workers (and robots) do not deter from the process or make something up "on the fly". The parts churn through the through the process, and the output is a finished product. It works well and companies achieve 99.99966% defect free products. Companies iron out inefficiencies over time. This is impressive and very well may be the sign of a mature industry.

In manufacturing a defined process can literally create the finished product. I don't think this is the case in software. We may have processes for source control, code review, check in sheets, requirements gathering, the SDLC, etc. But executing those processes does not in and of itself create a finished product. These processes may be beneficial, but are orthogonal to the actual creation.

Suppose your company is contracted to create software that will search millions of images to find the faces of a criminals. Despite the heavy process driven environment, the developer must engage in creating things "on the fly". Doing things on the fly is against the spirit of manufacturing. A good manufacturing process can be executed without thought by a robot.

For the creation of complex algorithms which have yet to be fathomed in the mind of a human, it is a necessity to create things on the fly. Software development is not the following of a process, but the creation of a processes to be exucuted by a computer. That is a fundamental difference. No matter how many orthogonal processes we put up around development, we will always resort to doing it "on the fly" when it comes to creation.

Everyone I talk to seems to agree with the manufacturing mindset. Am I alone in my thoughts?

Edit: I have accepted an answer. And my mind is made up.

[start lecture]

I declare the field of Software Engineering has grossly misunderstood the nature of processes. A process is a set of steps. If something can be expressed as a set of steps, it can be automated (or at least the high level aspects can be applied by rote). Automation cannot perform original creation, therefore all processes are orthogonal to creation.

I think our best bet is to come to terms that the processes that we adopt are orthogonal. We can never grow out of our "immaturity". It is the physics of creation that will keep us perceived as immature forever.

[/end lecture]

Answer 1

The fundamental difference between software development and manufacturing is that for software, the design phase is practically the entire thing. The actual production (assembly line part in traditional manufacturing) is a matter of copying a few files around. In software, the product design is the product.

So yes, we can learn from manufacturing processes, but only if we keep in mind that we have to look at the design phase, not the production phase, and that many manufacturing processes are built to cope with the specific limitations of an expensive production chain, which simply doesn't apply to software.

One example of a process model that works very well in software, but often fails horribly in product design, is iterative design - you start with a minimal prototype, and add features with each iteration. Building a prototype car to see what the new rear window knob design looks like is ridiculous, but in software, it makes sense (just hit F5 and wait a few seconds - voilà, ready to test drive).

If we do look at product design processes, the best industries to look at fall into two categories:

• those where production can be realized at commodity rates; e.g. the record industry (1% or less of the price for a CD is baking and printing), graphical media, etc.
• those where quantities are so low that the design phase is the most prominent cost factor (luxury articles, highly customized products, niche markets...)

It is a fundamental error to try and apply processes from physical manufacturing to software development: software development is not repetitive (if it is at your job, go find another job), it is only partially predictable, there are only very few physical limitations (hardware speed being one), and both the approach taken and the results can be highly personal. Applying assembly-line philosophies to what is basically a matter of analytic and creative thinking can (and often does) have devastating effects.

Answer 2

If you wanted to write the same exact software over and over again (as opposed to simply copying it) you could do that very efficiently via an assembly line.

But software creation is not a repetative task, each module is uniqe. That is why the comparison to manufacturing is invalid.

Answer 3

I think that the answer you are looking for is applicable or realistic here. What I feel like you want to know is how can we set our processes up to be more like the manufacturing industry. Instead I think the real question becomes "Knowing what manufacturing and other industries do to build quality products what can we learn?" or "What can the software industry do to improve quality?"

Unfortunately the answer to this is unclear because the software industry itself still does not know the answer. In order to be able to answer this the software industry needs to do research on what works and why? For example there have been studies that show that Test Drive Design (TDD) leads to an improvement in quality. Although the question of productivity still seems to be unanswered or at least not completely understood yet. As far as what the evidence shows so far:

• Code reviews are excellent, and shown to find the most bugs, but the effectiveness of a review drops fairly sharply after the first hour of review. Given that the average person can only read a few hundred lines of code an hour it suggests that developers should break changes up into smaller pieces.
• The longer it takes to find a bug the more expensive (time and money) it will be to fix it. So if a developer finds it while writing the code we say the cost is 1. If a unittest finds it later the cost is 10, if EVT finds it the cost is 100 and so on.
• There is some evidence that suggests the more complex the requirements are the more complex the solution is and the more complex the solution the more likely there will be bugs.

There is a man named Greg Wilson who gave an excellent talk about some of this a few years ago. Here is a link to the talk: Greg Wilson Talk

In addition to this I would say look back on your own work and find the themes with the types of errors that you introduce as well as which parts you struggle with. Compile these results and then create a checklist to insert into your process at difference places to help you do a better job. Personally I have looked back at the past few years of my work and found that there are some common themes to the problems I introduce. Specifically I have found that

• I don't often remember to build all the variants leading to me breaking the build.
• Many times I don't think about the following for each change. The good case, the bad case and the exceptional cases.
• All of the possible scenarios that might happen. Note that this is really hard because there are a lot of them.

Since I have found some themes to my errors I have created checklists that I automatically use, due to inserting them into my scripts, that help me work around these issues. There was a book written about this call the "Checklist Manifesto" which details how they can be put to good use. Personally I found it very insightful.

Answer 4

It's not about adopting "their" processes. It's about adopting "some" processes, that do not have the usual and well appreciated detriments of using assembly line processes for creative endeavours. The most important thing to note here is the idea that the quality of the processes translates directly to the quality of the product.

The best processes, or products for that matter, are the ones that fit the intended usage scenario like a hand in glove. The thing to think about is that actual code writing part is about the only one that is , atleast at a macroscopic level, not repetitive. All other facets, such as version control, bug tracking, planning, estimations, measurements etc. are, and use of a standard, tailored and proven process can help you at least in these areas.

So no, the software development process can not be likened to assembly line production and as such "their processes" are not OK, but the production design/product design phase of the product in a manufacturing industry can be the one to take inspiration from.

Answer 5

Question: Can we as developers learn from the processes of the manufacturing industry? Can adopting their processes increase the success rate of software development?

Answer: Yes, of course. There are many lessons that software developers can learn from manufacturing despite the fact that software development is a creative process. Software development is itself a process, and it includes many other processes. The better you can define and control those processes, the better you can control the process of software development overall. That doesn't mean that you should prescribe every keystroke a developer makes; it just means that as a developer, you naturally perform tasks in a certain order, and those tasks can often be managed. Here are some examples:

• defect tracking: When a bug is observed or reported, what happens to it? Do you write it down on a scrap of paper and stick it on an 'investigate' spike? Do you later remove those scraps one at a time, investigate them, and eventually move them to the 'resolved' spike? If you do that without fail every time you get a bug report, you've got a well-defined, measurable process, and you're probably much better off than someone who has a fancy, high-tech defect tracking system that's so onerous that some team members track bugs other ways, or not at all.

• version control: There's a good chance that you use version control where you work, and version control is obviously a lot more useful when everyone uses it the same way.

• product design: Do you decide which features to implement by throwing darts at a wall covered with post-it notes? If so, you've got a process. I don't think anyone would argue that it's a great process, but at least it's a starting point. If you change the process how can you know for certain that your change was actually an improvement unless you measure before and after? You can't.

• code reviews: Would a code review be useful if the review process and coding criteria changed for each review? Of course not.

• software development life cycle: The whole analysis -> design -> implementation -> test -> maintenance cycle is a process that should be defined clearly.

In each of these cases, having a process in place lets you measure inputs and outputs and determine whether changes you make have the intended effect. Not having processes in place means that you're just guessing when you try to improve the way you work. This is really what manufacturing is all about, and it only makes sense to borrow the successive refinement tools of manufacturing when they're appropriate.

There's an entire field devoted to defining and improving processes used to create and maintain software; it's called software engineering. It's no surprise that you have questions about the development process while reading about CMMI -- CMMI is a product of the Software Engineering Institute.

Software development has already adopted many manufacturing concepts:

• It's hard not to see the influence of Eli Whitney's interchangeable parts on both OOP and component-based development.

• Project management techniques used in software development aren't very different from those developed for manufacturing. As just two examples, the software world has only recently adopted the Kanban concept that was developed decades ago at Toyota, and Gantt charts were used in manufacturing long before the first electronic computer was built.

• Quality management methodologies like Six Sigma that were developed for manufacturing have been adapted to software development.

Despite the heavy process driven environment, the developer must engage in creating things "on the fly".

Are you telling me that someone is going to decide on their own to add a patch to the facial recognition package, and they're going to add it into the production build without first creating an issue in the tracking system, having the design reviewed, checking the code into version control, or having the testing folks look at it first? Our process requires those things for some very good reasons. If by "on the fly" you mean "outside the process," that's unacceptable.

Doing things on the fly is against the spirit of manufacturing.

Again, if "on the fly" means "outside the process," you're right. But if you think that manufacturing doesn't require quick thinking and developing creative solutions to problems, you're wrong. All kinds of problems come up in the manufacturing process -- the cupcakes don't have enough cream filling, painted surfaces suddenly stop passing QA's scratch test, 20% of finished parts are missing an important retaining ring, the dough mixing system has broken a critical part...