[Zigurd]

Deming is talking about repeatable manufacturing processes. The point of Statistical Process Control is that you sample metrics that tell you if the process will produce products reliably within tolerances.

Software is completely different, it is hardly ever a repeatable process to create software. Making the same software over and over is nonsensical, but making a billion identical contact lenses is exactly what you want.

There are forms of software "inspection," like pair programming, that amount to what Deming says you should not do in manufacturing: Inspect everything. But pair programming is pretty rare. Other practices like code review have been called into question. So it may still be true that you can't inspect your way to quality in software, but not for the same reasons that it is a bad idea in many cases in manufacturing.

[hikarudo]

> Software is completely different, it is hardly ever a repeatable process to create software. Making the same software over and over is nonsensical, but making a billion identical contact lenses is exactly what you want.

I've heard it said like this: Creating a software is like developing a recipe for a cake. Baking thousands of cakes (a "manufacturing process") is what you do once you have the recipe. The two activities are very different.

[Jtsummers]

Kind of. We have to clarify what we mean by "creating a software".

This seems to be rarely done in most discussions on processes for software development. The lack of information regarding this means that everyone gets to be right and angry at everyone else.

Are you making novel systems? Then it's like developing a recipe for a cake. Are you making bog standard CRUD web apps? Then you're baking thousands of cakes.

A lot of software development sits somewhere in between these two extremes. It has repeatable, well-established portions that can be executed almost mechanically, and portions that require you to sit down and collaborate or really think about what you're doing. How these balance out on a project determines what approaches are appropriate to even consider.

Then there's software maintenance (an unfortunately neglected aspect of software in many parts of this industry). Here the same consideration applies. Are you writing new software that's really just generating new kinds of custom reports? That's rather mechanical, you may even be able to automate yourself out of a job. Or are you adding truly novel features, extending your document editor to support real-time networked collaboration?

Software runs the full gamut so no statement about what software is will ever be correct. We can only discuss the utility or applicability of processes once we specify which kinds of software activities we're involved in.

[Zigurd]

Certainly some software looks routine and feels repetitious while you are doing it. But very little if any software is amenable to determining its manufacturing tolerances. That phrase is jarring because the idea of manufacturing tolerances for software does not make sense. But manufacturing tolerances are fundamental to statistical process control, which then builds on statistically valid sampling to determine if part of a process is failing. (Or it can determine that a quality issue is something other than a process failure.) But it depends on setting and using manufacturing tolerances wisely.

[s-luv-j]

You are 100% right that measuring the process of creating software is a terrible application of statistical process control. See Jira.

One way to look at how Deming/Shewart's work applies to software is to consider what happens when you apply their statistical analysis techniques to running software.