6 ms·

No! No! No! No! WHY?? We spend years saying "software development is not manufacturing", and now it the name of "agile" we allow all this to crept back. Your te

No! No! No! No! WHY?? We spend years saying "software development is not manufacturing", and now it the name of "agile" we allow all this to crept back. Your team is not falling behind, your estimates were wrong!!

__alexs 11y ago
I've usually assumed that when people say "software development is not manufacturing" they usually are referring to the "Western" model of manufacturing that the first half Goldratt's book Critical Chain spends tearing apart.
humanrebar 11y ago
> Your team is not falling behind, your estimates were wrong!! Or your business model doesn't support your technical goals. That is, your business model doesn't work. "I don't know yet. I need three days and I'll give you a better answer." is often a great estimate.
- pc86 11y ago
  The number of times I've had someone bring up a feature at 9:02 am (usually on the phone with six other people, of course) and wonder why I won't "ballpark it" at 9:08 is mind boggling.
kyllo 11y ago
That response is ineffective, because the managers will simply pressure the engineers to give better estimates. The penny game (where I work we call it the beer game) is a good learning exercise, but in software development you really don't want to be having different "stations" handing work off to each other in the first place, because that leads to delays and quality issues. Each station will develop its own little backlog and pretty soon a feature cannot make it from start to finish without spending weeks waiting in the design queue, then the dev queue, then the test queue... Instead, you need to have a small, cross-functional team focusing on the same piece of the product at the same time, collaborating and giving rapid feedback on each other's work--that's what agile and XP and scrum are for. And you need a pull system instead of a push system, to regulate the amount of work in progress--that's what kanban boards are for.
- gclaramunt 11y ago
  I don't like kanban either, still manufacturing
  - nradov 11y ago
    And yet we have existence proofs that Kanban works, in the sense that it allows many teams to quickly deliver value to customers. So what don't you like about it? We shouldn't reject innovations out of hand just because they happen to originate in manufacturing.
    - Chris2048 11y ago
      By that logic, homeopathy must also be legit.
- mtviewdave 11y ago
  But doesn't specialization naturally push towards the creation of stations? If your cross-functional team contains both a database engineer and a UX designer, I don't see how either can help with the other's job.
  - fireflash38 11y ago
    I find it's helpful to at least be aware of what is going on with other 'specialists'. That way you can hopefully get some mental (or physical!) prep done long before it gets to you.
  - kyllo 11y ago
    It really can help if they are actively communicating with each other--the user interface is how the data gets into the system, so if the database engineer understands the interface it can provide context for where the data comes from, what it means and how it is used, and that can inform data modeling decisions. Understanding how the data model is laid out, how much structure is needed, what fields are required/optional and what types they are etc. can also inform UI/UX design decisions. And this is an example of two roles that are at opposite ends of the frontend/backend spectrum. For roles whose work products interface directly, there's an even stronger need to collaborate. Specialization is good in that it allows people to focus on using their best skills, but it's bad if it fragments the product development team and inhibits communication and decisionmaking.
UK-AL 11y ago
That's because your thinking of the manufacturing model of low skilled, ignored workers cranking out widgets in big batches. Lean, and Japanese manufacturing the worker has a lot power(They can stop the line) and have final say in quality.
- gclaramunt 11y ago
  No, I know about pull, Toyota, Lean, and all that. Still manufacturing and production of repeatable widgets... Will you apply the same approach to make a bunch of mathematicians prove a theorem?
  - kyllo 11y ago
    Most computer programming (in the private sector) is not research. It is product development. It is much more like designing and prototyping a physical product like an automobile, than it is like proving a theorem.
    - sheepmullet 11y ago
      Is there any evidence that design work and prototype work is done in the same fashion as manufacturing by these Japanese firms?
      - gclaramunt 11y ago
        FWIW, it appears that the software development process in Toyota is pretty screwed, and the bugs that saw the light lately seems to confirm it
mcphage 11y ago
> Your team is not falling behind, your estimates were wrong!! This article isn't about meeting (or failing to meet) deadlines, it's about work-in-progress building up.
- gclaramunt 11y ago
  building up with respect to what?
- debacle 11y ago
  work-in-progress build up is only a problem if you're not meeting deadlines.
  - lmm 11y ago
    No, it's a problem for throughput even if you don't have deadlines. Limiting work in progress is possibly the heart of agile.
    - gclaramunt 11y ago
      In my experience, throughput is never constant... how do you know where is the limit?
      - lmm 11y ago
        There are fluctuations to be sure, but I think you can compare against estimates under two different methodologies and see whether you seem to perform better under one or another. (Of course you have to weigh the benefit of such measurements against the costs of making those estimates). To my mind the costs of context switching are pretty well established at this point and the value of limiting work in progress is clear enough from experience, but that's just my experience and maybe you disagree.
        gclaramunt 11y ago
        I don't disagree with the cost of context switch and I see value in limiting the work in progress, my argument is against focusing on throughput and measuring it by units of work, and particularly using estimates as the base of the measure
marcosdumay 11y ago
That model applies to any activity with sequential steps. This is modeling how people organize in hard Math, and getting real results to improve a situation. It is not equating software to manufacturing.

__alexs 11y ago

I've usually assumed that when people say "software development is not manufacturing" they usually are referring to the "Western" model of manufacturing that the first half Goldratt's book Critical Chain spends tearing apart.

humanrebar 11y ago

> Your team is not falling behind, your estimates were wrong!! Or your business model doesn't support your technical goals. That is, your business model doesn't work. "I don't know yet. I need three days and I'll give you a better answer." is often a great estimate.

pc86 11y ago
The number of times I've had someone bring up a feature at 9:02 am (usually on the phone with six other people, of course) and wonder why I won't "ballpark it" at 9:08 is mind boggling.

kyllo 11y ago

That response is ineffective, because the managers will simply pressure the engineers to give better estimates. The penny game (where I work we call it the beer game) is a good learning exercise, but in software development you really don't want to be having different "stations" handing work off to each other in the first place, because that leads to delays and quality issues. Each station will develop its own little backlog and pretty soon a feature cannot make it from start to finish without spending weeks waiting in the design queue, then the dev queue, then the test queue... Instead, you need to have a small, cross-functional team focusing on the same piece of the product at the same time, collaborating and giving rapid feedback on each other's work--that's what agile and XP and scrum are for. And you need a pull system instead of a push system, to regulate the amount of work in progress--that's what kanban boards are for.

gclaramunt 11y ago
I don't like kanban either, still manufacturing
- nradov 11y ago
  And yet we have existence proofs that Kanban works, in the sense that it allows many teams to quickly deliver value to customers. So what don't you like about it? We shouldn't reject innovations out of hand just because they happen to originate in manufacturing.
  - Chris2048 11y ago
    By that logic, homeopathy must also be legit.
mtviewdave 11y ago
But doesn't specialization naturally push towards the creation of stations? If your cross-functional team contains both a database engineer and a UX designer, I don't see how either can help with the other's job.
- fireflash38 11y ago
  I find it's helpful to at least be aware of what is going on with other 'specialists'. That way you can hopefully get some mental (or physical!) prep done long before it gets to you.
- kyllo 11y ago
  It really can help if they are actively communicating with each other--the user interface is how the data gets into the system, so if the database engineer understands the interface it can provide context for where the data comes from, what it means and how it is used, and that can inform data modeling decisions. Understanding how the data model is laid out, how much structure is needed, what fields are required/optional and what types they are etc. can also inform UI/UX design decisions. And this is an example of two roles that are at opposite ends of the frontend/backend spectrum. For roles whose work products interface directly, there's an even stronger need to collaborate. Specialization is good in that it allows people to focus on using their best skills, but it's bad if it fragments the product development team and inhibits communication and decisionmaking.

UK-AL 11y ago

That's because your thinking of the manufacturing model of low skilled, ignored workers cranking out widgets in big batches. Lean, and Japanese manufacturing the worker has a lot power(They can stop the line) and have final say in quality.

gclaramunt 11y ago
No, I know about pull, Toyota, Lean, and all that. Still manufacturing and production of repeatable widgets... Will you apply the same approach to make a bunch of mathematicians prove a theorem?
- kyllo 11y ago
  Most computer programming (in the private sector) is not research. It is product development. It is much more like designing and prototyping a physical product like an automobile, than it is like proving a theorem.
  - sheepmullet 11y ago
    Is there any evidence that design work and prototype work is done in the same fashion as manufacturing by these Japanese firms?
    - gclaramunt 11y ago
      FWIW, it appears that the software development process in Toyota is pretty screwed, and the bugs that saw the light lately seems to confirm it

mcphage 11y ago

> Your team is not falling behind, your estimates were wrong!! This article isn't about meeting (or failing to meet) deadlines, it's about work-in-progress building up.

gclaramunt 11y ago
building up with respect to what?
debacle 11y ago
work-in-progress build up is only a problem if you're not meeting deadlines.
- lmm 11y ago
  No, it's a problem for throughput even if you don't have deadlines. Limiting work in progress is possibly the heart of agile.
  - gclaramunt 11y ago
    In my experience, throughput is never constant... how do you know where is the limit?
    - lmm 11y ago
      There are fluctuations to be sure, but I think you can compare against estimates under two different methodologies and see whether you seem to perform better under one or another. (Of course you have to weigh the benefit of such measurements against the costs of making those estimates). To my mind the costs of context switching are pretty well established at this point and the value of limiting work in progress is clear enough from experience, but that's just my experience and maybe you disagree.
      - gclaramunt 11y ago
        I don't disagree with the cost of context switch and I see value in limiting the work in progress, my argument is against focusing on throughput and measuring it by units of work, and particularly using estimates as the base of the measure

marcosdumay 11y ago

That model applies to any activity with sequential steps. This is modeling how people organize in hard Math, and getting real results to improve a situation. It is not equating software to manufacturing.