alt Hacker NewsThe main point that I did not see mentioned in this piece is that Deming should only be applied to MANUFACTURING environments, because things like engineering are too chaotic to identify processes or trends in the engineering itself, and trying to control those engineering processes with SPC doesn't really improve the quality of the engineering, it just adds stress, makes things take longer, and probably lowers the quality of the thing that is being engineered.
Obviously, if a quality issue is detected in manufacturing, there may be some steps that engineering could take to improve the manufacturing process and make things stable enough to obtain meaningful statistics. This is part of the Deming feedback process, and part of the System Engineering Life Cycle.
Replies
I think you're confusing Deming with statistical process control.
It is true that SPC works best for the non-chaotic parts of product development and manufacturing alike. There are parts of product development that are non-chaotic, and SPC works just fine there, too.
In addition to SPC, Deming had strong opinions on how organisations ought to work and these are relevant also for product development. These are things like
- Understand the underlying customer need.
- The leaders shape the output of the organisation by shaping its processes.
- It is cheaper and faster to build quality and security into the product from the start instead of trying to put it in at the end.
- Close collaboration with suppliers can benefit both parties.
- Have leaders skilled in whatever their direct reports are doing. Use them as coaches normally and as spare workers in times of high demand.
- Collaborate across parts of the organisation instead of throwing things over walls.
- Don't just tell people to do better. Show them how they can do better. Give them the knowledge, tools, and authority they need to do better.
These are just as relevant for product development as for manufacturing. If anything, even more so, thanks to the chaotic nature of product development.
I think Donald G. Reinertsen did a good job in his books applying Deming to the design process.
The core issue with the article is that author mixes up bad management and "fog of management" with the fact that financial results have a disproportionate amount of influence in how things are organised. Every team and employee should do their part to contribute to the financial targets every quarter and within the fiscal year. Which clashes with Deming's points 11b and 12b [1].
_________
> trying to control those engineering processes with SPC doesn't really improve the quality of the engineering, it just adds stress, makes things take longer, and probably lowers the quality of the thing that is being engineered
Totally depends on the scale. For pizza-sized times with a neighbourhood pizza shop sized impact, sure. Large scale projects without controls & feedback loops in place will fall apart; see: Scaling teams: https://archive.is/FQKJH
If you'd follow some medium to large scale projects (like Go / Chromium), the value of processes & quality control, even if it may seem at the expense of velocity, becomes clear.
The great insight of Deming's methods is that you can (mostly) identify the difference between common and special causes mathematically, and that you should not attempt to fix common causes directly - it's a waste of time, because all real-life processes have random variation.
Instead, what you want to do is identify your mean and standard deviation, plot the distribution, and try to clean it up. Rather than poking around at the weird edges of the distribution, can we adjust the mean left or right to get more output closer to what we want? Can we reduce the overall standard deviation - not any one outlier - by changing something fundamental about the process?
As part of that, you might find out that your process is actually not in control at all, and most of your problems are "special" causes. This means you're overdriving your process. For example, software developers working super long hours to meet a deadline might produce bursts of high producitivity followed by indeterminate periods of collapse (or they quit and the whole thing shuts down, or whatever). Running them at a reasonable rate might give worse short-term results, but more predictable results over time, and predictable results are where quality comes from.
Distributed systems is also a way to be throughly humbled by complexity: https://fly.io/blog/corrosion/
Having worked on software that runs manufacturing plants your comment echos the idea that too many engineers have that they are "better" than manufacturing and lessons don't apply to them.
Go back to your desk and work on a PR that is going to go through a 20 step process that is constantly changing before a hopefully semi-regular release goes out to customers and tell me how you ignoring all of knowledge on how to do this well is good for your career.
For a long time I assumed folks like you were simply uneducated, but know I see it for what it is, elitism.
Deming's observations and suggestions can be widely implemented.
- Process improvement can be applied all over the place. In how you merge PRs, how you run tests, how you manage sprints, how you deploy safely, etc
- SPC is just used to identify defects. It does not inherently create stress; how you use it matters
- You can identify quality issues in any engineering discipline. High-level method: identify a quality measure ("time to merge PRs", "website is up", "tests are not flaky"), observe it, record the observation, plot it on a chart. Chart trends down? Quality issue. Process improvement cycle to attempt a fix. Chart trends up? Quality issue abated. Must add intelligent study/reasoning though, not just chase metrics.
- Training workers improves output by ensuring there is uniform and correct knowledge of tasks required. Software engineering is particularly guilty of hiring workers without ever giving them specific training, and it results in frequent mistakes from simply not understanding the technology they're using (most devs today will probably never read an entire technical manual).
- Look at the rest of his advice. Drive out fear (improving trust in changes allows shipping more changes faster), improve leadership (help staff improve, don't just make sure they're writing code), break down barriers (improving cross-team collaboration makes changes easier and better), eliminate numerical quotas (focus on quality over quantity makes a better product), remove barriers to pride of workmanship (a dev that makes good code is a happy dev), institute education and self-improvement (brings in new techniques that improve output), take action for transformation (make everyone responsible for improving the org), improve constantly (look for ways to improve, don't coast), etc. All these apply to SWE.