Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why limiting work-in-progress works

lethain.com

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Why limiting work-in-progress works

#11

Post by JoshTko »

xiphias2 wrote: post #6
closeparen wrote: post #4

Two of the most under-appreciated insights in software engineering: concurrent work in progress has a productivity cost, and team size has a productivity cost (The Mythical Man Month). If you ever want to see cognitive dissonance in action, try talking about this with engineering managers at a hypergrowth company. They will smile and nod and agree and go right back to pushing for ever increasing scope + headcount and…

I have seen this change when I was working at Google. The key problem was that the PM to Engineer ratio increased in the company, and we were getting a lot of extra work from the PMs that looked nice on paper, were easy to understand, but didn't have a real positive impact on the customer. This extra work completely blocked us from improving the performance of the product.

As a PM I'm curious what type of work that falls into this category. Also curious if this was specifically coming from the PM or if it was coming from above.

Re: Why limiting work-in-progress works

#12

Post by xiphias2 »

JoshTko wrote: post #11
xiphias2 wrote: post #6

Earlier quoted context omitted.

I have seen this change when I was working at Google. The key problem was that the PM to Engineer ratio increased in the company, and we were getting a lot of extra work from the PMs that looked nice on paper, were easy to understand, but didn't have a real positive impact on the customer. This extra work completely blocked us from improving the performance of the product.

As a PM I'm curious what type of work that falls into this category. Also curious if this was specifically coming from the PM or if it was coming from above.

It usually came from sales and other teams. The big difference that I saw is that in the past to give an engineering team work from another team meant that the other team's TL had to convince the TL of the team to take the work, and the TL had enough context to push back (which I believe is the best thing to do in most of the cases).

In the old Google PMs were working on promoting the work of engineering teams and communicating with sales/ops, but didn't have a strong power over the direction of the work of the engineering teams. Their time was a scarce resource to be used by the team, not extra bosses. In the new Google, PMs have a lot of time that they are using for fighting with each other to have some feature implemented that they are pushing.

Also the best PMs in the old Google had some engineering background, and were doing log analysis without asking help from the engineers for every question.

Re: Why limiting work-in-progress works

#13

Post by adrianmonk »

nkingsy wrote: post #7

Slow CI and/or Code Review makes concurrent work a bit of a necessity. Context switching certainly has a cost, but it's cheaper for my employer than paying me to wait for tests to run.

The trouble is, it can have a snowball effect.

Say I'm multiplexing my available hours among three things, but I get blocked sometimes. So in an effort to avoid ever having time wasted because I'm idle, I switch to having five active things instead.

Now it takes longer for me to cycle around among those things. So the people who are waiting on me for code reviews have to wait longer. They also decide to switch from having three things on their plate to five things on their plate.

Now I'm waiting even longer for their code reviews because it also takes them longer to cycle back around. I start thinking about switching from five things on my plate to seven things on my plate.

It may not really spiral out of control this bad, but it does have a bit of a tendency to self reinforce.

Sometimes it really is a good idea, but the point is there is a trade-off. In some cases, a little idle time can cost less than the problems caused by everybody juggling more stuff.

In real life, things are complicated. Not everything I'm blocked on is another person. Some tasks I need to get done don't block someone else. If I submit my travel expense report a week later, I'll just get reimbursed in a different pay period, so turnaround time doesn't matter there like it does when someone else is depending on me to unblock them.

Re: Why limiting work-in-progress works

#14

Post by Gibbon1 »

closeparen wrote: post #4

Two of the most under-appreciated insights in software engineering: concurrent work in progress has a productivity cost, and team size has a productivity cost (The Mythical Man Month). If you ever want to see cognitive dissonance in action, try talking about this with engineering managers at a hypergrowth company. They will smile and nod and agree and go right back to pushing for ever increasing scope + headcount and…

On the wall of my dad's office in the 1970's was the universal problem solving flow chart. And a poster that said putting more people on a project in trouble is like putting out a fire with gasoline.

I follow the former when maintaining software/hardware. And totally seen the second in action. Add more people to the project and watch the deadline slip another couple of months automagically.

Also remember first company I worked at. The shop eventually adopted a policy at my suggestion. If it isn't ready to be boxed up and shipped when people come back from lunch, it's not shipping today. That put a stop the constant Chinese fire drill of trying to get stuff out the door before UPS came. Perversely we started shipping more stuff on time.

Re: Why limiting work-in-progress works

#15

Post by donmcc »

marcosdumay wrote: post #5
klenwell wrote: post #2

So having read the article, why does limiting work-in-progress work? Because it allows you to finish more work that you start? I struggled a little bit initially with the generic concepts used for modeling. But I suppose the real insight is that, focusing only on these 3 basic parameters (work started, work finished, and number of developers), you can get wildly different results. Is that a fair reading? This is a to…

> So having read the article, why does limiting work-in-progress work? I imagine his models are those code blocks just above the images. A reference to the language those are written on would be great, and would let we check if the code is really realistic. But it's lacking, so I can't explain why the article claims this. Limiting WIP happens to work on practice, and is the basis of the kanban process (both the one w…

Looking through past posts, it looks like the author used this: https://lethain.com/systems-jupyter-notebook/

Re: Why limiting work-in-progress works

#16

Post by donmcc »

nkingsy wrote: post #7

Slow CI and/or Code Review makes concurrent work a bit of a necessity. Context switching certainly has a cost, but it's cheaper for my employer than paying me to wait for tests to run.

This is widely believed but I think in most cases not true. Goldratt’s ‘The Goal’ https://www.amazon.com/Goal-Process-Ongoing-Improvement-eboo... illustrates how this works in a factory setting, but you can apply the principles to most work processes.

Re: Why limiting work-in-progress works

#17

Post by marcosdumay »

donmcc wrote: post #15
marcosdumay wrote: post #5

Earlier quoted context omitted.

> So having read the article, why does limiting work-in-progress work? I imagine his models are those code blocks just above the images. A reference to the language those are written on would be great, and would let we check if the code is really realistic. But it's lacking, so I can't explain why the article claims this. Limiting WIP happens to work on practice, and is the basis of the kanban process (both the one w…

Looking through past posts, it looks like the author used this: https://lethain.com/systems-jupyter-notebook/

Oh, thanks.

So the article just postulates that started WIP projects slow down developers on a linear basis. So when he takes away that slow-down, things get faster.

Post reply on HN