Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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]

share|improve this question

closed as not constructive by Ross Patterson, Martijn Pieters, gnat, thorsten müller, Kilian Foth Apr 30 '13 at 6:56

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

1  
FYI: What motivated me to ask this question was a CMMI book. It compared software creation to manufacturing and concluded the Soft.Ind. was immature. –  Lord Tydus Dec 9 '11 at 4:00
3  
I'd say that a more accurate analogy in the same field would be the engineering involved in designing and setting up your factory. That's where the creative/difficult bits happen. The rest is just nuts and bolts, just like for us the rest is just 1s and 0s. –  Benjol Dec 9 '11 at 7:23
    
Software engineering doesn't compare to manufacturing. It compares to craftsmanship. This cannot be reduced to an industrial process. –  mouviciel Dec 9 '11 at 8:34
1  
There is a reason why it is called software development. Not software manufacturing. Think product development vs product manufacturing. –  tehnyit Dec 9 '11 at 9:37
    
Didn't the Japanese try just that: to create software in a process more geared toward the manufacturing of physical goods? As I recall, it's pretty widely regarded as a complete and utter failure, even though of course there is some successful Japan-developed software titles (try Sonic the Hedgehog for an example). –  Michael Kjörling Dec 9 '11 at 9:51

5 Answers 5

up vote 33 down vote accepted

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.

share|improve this answer
2  
Great answer. In software development everything is a prototype! –  James Anderson Dec 9 '11 at 7:49
1  
It's a good point, but I think the design aspect is overstated. You hear numbers thrown around, like "60% of the cost of software is maintenance" and "the last 10% of a software project takes a lot more than 10% of the schedule." The numbers don't matter so much as the idea here, and both maintenance and polishing happen well after the design has been finalized. Design is doubtless a significant aspect of the product, but it's also arguably the easiest and cheapest part. –  Caleb Dec 9 '11 at 8:30
3  
@Caleb: Except maintenance, especially for a well designed product, is mostly not about fixing bugs in the current product, but about adding features, in other words adding and changing the design. –  Marjan Venema Dec 9 '11 at 8:41
    
@Caleb - this is probably true of setting up a production line and production processes as well. Setting up the production line is one of the single most expensive and time consuming aspects of the manufacturing process. –  James Anderson Dec 9 '11 at 8:59
2  
@Caleb: I think you misunderstood my analogy here. When I'm talking about 'design', I'm talking about product design, that is, the process that precedes starting the assembly line. Both the design and implementation phases of a software product are 'design' in this sense, while the manufacturing part is reduced to uploading binaries to a server or baking DVD-ROMs for shipping. As a programmer, all you ever deliver is a prototype; so everything you do, including maintenance work, is 'design' in the traditional production chain analogy. –  tdammers Dec 9 '11 at 12:37

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.

share|improve this answer
    
Taking lessons from manufacturing doesn't mean building a software assembly line. Manufacturing has a lot to say about process improvement, and there's plenty in the software development process that could stand improving. –  Caleb Dec 9 '11 at 7:44
    
@Caleb: What lessons do you mean then? That's exactly what I thought you meant. –  sevenseacat Dec 9 '11 at 8:16
    
@Karpie, process improvement can happen even when you're producing things that aren't identical. How many bugs did we write this month? Last month? Two months ago? If that number changes significantly from one month to the next, you should figure out why. This is the sort of thing that works for any process, whether you're producing identical widgets on an assembly line or feature films in a highly creative process. –  Caleb Dec 9 '11 at 8:38

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.

share|improve this answer

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.

share|improve this answer

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...

share|improve this answer
    
+1. Exactly my thoughts. But I am afraid, this might not be a popular response, because in an immature software engineering state, cowboy coding is the done thing. Even within CMMI, at L1, the heroes are worshiped as deities. –  Vaibhav Garg Dec 9 '11 at 7:09
    
@Vaibhav Garg: I believe that in the long run, the process that works best, in the business sense, wins. If controlled "software engineering process" results in higher quality*speed/cost ratio, then it wins. Sometimes cowboy coding seems to produce in annoyingly good results though. –  Joonas Pulakka Dec 9 '11 at 8:16
1  
@JoonasPulakka. I agree, that sometimes cowboy coding seems to produce good results. But the key here is "sometimes". If you aim for repeatability in performance, you have to be repeatable in what you do. Think the P in SIPOC! –  Vaibhav Garg Dec 9 '11 at 9:07
1  
@JoonasPulakka- Quoting verbatim from the CMMI Standard for level 1 organisations: Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. In spite of this chaos, maturity level 1 organizations often produce products and services that work; however, they frequently exceed their budgets and do not meet their schedules. –  Vaibhav Garg Dec 9 '11 at 9:09
2  
"Success in these organizations depends on the competence ... of the people" I don't think any process can change that. –  kevin cline Apr 29 '13 at 18:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.