4 ms·

I have seen the Lean/Six sigma people trying to apply manufacturing principles to software and it's the main reason I left my previous employer. For things to b

I have seen the Lean/Six sigma people trying to apply manufacturing principles to software and it's the main reason I left my previous employer. For things to be measured in a way that can be compared, things need to be standardized. In manufacturing, you have a standardized product that you can improve upon. All sort of things are being repeated exactly the same way. In software, we have repeating ourselves. There is no process that can be measured in a similar manner.

kqr 5y ago
Well... You're right, of course. Development by definition requires novelty. If we just built the same thing over and over, we wouldn't be developing. We'd be manufacturing. But development still does entail repetition on some level. We pull features through the implementation process, over and over again. We review code, over and over again. We hold retrospectives, over and over again. We do status updates, over and over again. We make supposedly backwards-compatible changes, over and over again. We deprecate features, over and over again. If you look, you can find all sorts of things that repeat. These things can actually benefit from being standardised. Standardisation does not mean preventing any future changes; it means doing things consistently, and systematically evaluating and implementing proposed improvements. But why bother? You can't improve anything unless you can do it consistently. You avoid spending creative energy on repetitive processes, and can use it where it matters: on the actual development. You can learn faster what does and doesn't work, because everyone does the same thing on the same schedule.
- ChrisMarshallNY 5y ago
  A big difference between software and hardware, is that Development, Manufacturing, and Distribution are pretty much all the same thing. One person can create, duplicate, and distribute earth-shattering functionality. They can then, iteratively, improve or alter the product, almost in "live" fashion. Manufactured goods have a lot of constraints that come from rather immutable structures; like the laws of physics. There's usually a number of parallel engineering efforts that converge, and that's before the product even rolls off the assembly line. Once there, it still needs to be placed in position to be accessed by the end users. Each of these steps are quite different from the others, and require a confluence of disciplines, skills, and experience. Many of them can be subjected to measurable process. Maybe only the initial engineering step could be fairly compared to software development. Even then, prototyping introduces some considerable structure.
mumblemumble 5y ago
Software throughput may not be quite so standardized, and that might prevent you from applying every single nitty gritty specific improvement that someone found in a maufacturing-oriented LSS implementation. But there are still things you can meaningfully quantify. The thing that Kanban software development chooses to focus on, lead time, would be my top candidate. That seems universal. I'm guessing most others would be team-specific things that come out of a DMAIC analysis. If you've got a problem with too much rework due to team miscommunication, the specifics of how you measure that are going to depend a lot on how your team defines rework in the first place.
908B64B197 5y ago
> I have seen the Lean/Six sigma people trying to apply manufacturing principles to software That's great. It tells you which stock to short.

kqr 5y ago

Well... You're right, of course. Development by definition requires novelty. If we just built the same thing over and over, we wouldn't be developing. We'd be manufacturing. But development still does entail repetition on some level. We pull features through the implementation process, over and over again. We review code, over and over again. We hold retrospectives, over and over again. We do status updates, over and over again. We make supposedly backwards-compatible changes, over and over again. We deprecate features, over and over again. If you look, you can find all sorts of things that repeat. These things can actually benefit from being standardised. Standardisation does not mean preventing any future changes; it means doing things consistently, and systematically evaluating and implementing proposed improvements. But why bother? You can't improve anything unless you can do it consistently. You avoid spending creative energy on repetitive processes, and can use it where it matters: on the actual development. You can learn faster what does and doesn't work, because everyone does the same thing on the same schedule.

ChrisMarshallNY 5y ago
A big difference between software and hardware, is that Development, Manufacturing, and Distribution are pretty much all the same thing. One person can create, duplicate, and distribute earth-shattering functionality. They can then, iteratively, improve or alter the product, almost in "live" fashion. Manufactured goods have a lot of constraints that come from rather immutable structures; like the laws of physics. There's usually a number of parallel engineering efforts that converge, and that's before the product even rolls off the assembly line. Once there, it still needs to be placed in position to be accessed by the end users. Each of these steps are quite different from the others, and require a confluence of disciplines, skills, and experience. Many of them can be subjected to measurable process. Maybe only the initial engineering step could be fairly compared to software development. Even then, prototyping introduces some considerable structure.

mumblemumble 5y ago

Software throughput may not be quite so standardized, and that might prevent you from applying every single nitty gritty specific improvement that someone found in a maufacturing-oriented LSS implementation. But there are still things you can meaningfully quantify. The thing that Kanban software development chooses to focus on, lead time, would be my top candidate. That seems universal. I'm guessing most others would be team-specific things that come out of a DMAIC analysis. If you've got a problem with too much rework due to team miscommunication, the specifics of how you measure that are going to depend a lot on how your team defines rework in the first place.

908B64B197 5y ago

> I have seen the Lean/Six sigma people trying to apply manufacturing principles to software That's great. It tells you which stock to short.