let me recommend
https://www.tbray.org/ongoing/When/202x/2020/07/05/Too-Effic...
on this topic. Tim Bray's writing is always worth reading, but I think he's really valuable on this specifically.
Efficiency is the enemy? (2021)
31–40 of 73 posts
Re: Efficiency is the enemy? (2021)
#32Slack is great for resiliency, but it obviously can't be unbounded. The CEO in the article can't have 100 secretaries just in case. One of the great things about approaches like linear programming (programming in the sense of industrial engineering and not CS) is that it helps quantify how much that slack is worth. It can then be put into context of whether the risk tradeoff is worth the extra slack.
In a world where CEO time is apparently worth like 300X worker time, how many secretaries is the right number? I guess it is however many it takes to keep the CEO completely saturated with work...
Re: Efficiency is the enemy? (2021)
#33Efficiency sounds so nice, but ever since working on a safety based project and observing
1) Efficiency hates redundancy
2) Redundancy is, like, the easiest, most zero-thought way of adding robustness
I've been a little suspicious of efficiency.
And we see questionable efficiency optimizations all over -- here in an individual business, in the greater economy (Let's over-specialize our economies, it is more efficient. Let's JIT manufacture everything, buffers cost warehouse space).
Just add redundancy. It'll be twice as expensive but it won't explode if something goes wrong.
Re: Efficiency is the enemy? (2021)
#34Slack is great for resiliency, but it obviously can't be unbounded. The CEO in the article can't have 100 secretaries just in case. One of the great things about approaches like linear programming (programming in the sense of industrial engineering and not CS) is that it helps quantify how much that slack is worth. It can then be put into context of whether the risk tradeoff is worth the extra slack.
In a world where CEO time is apparently worth like 300X worker time, how many secretaries is the right number? I guess it is however many it takes to keep the CEO completely saturated with work...
That's exactly what my GP was commenting on. Instead of using heuristics like "however many it takes the CEO completely saturated with work" or assuming the CEO worth is 300x the secretary, you can quantify it. As soon as the value of the additional slack (organizational value or risk balance) is outpaced by the slack cost (secretary salary), you know you've added too much slack.
Re: Efficiency is the enemy? (2021)
#35Earlier quoted context omitted.
It always reminds me of a fire brigade or an army. You want the firefighters to have lots of slack so that they will be available when there is a fire. On the other hand, having people sitting around "being ready" is costly and there is some optimum amount you need.
The timescale makes a huge difference here. Firefighters need to be next to their equipment to respond to an emergency. US army reservists “One Weekend a Month, Two Weeks a Year” is understating things, but they can hold down a full time job when not called up.
What I meant was that both professions are good examples of "slack-full" professions. They can still be considered to be doing their job well even if they're not actively fighting (either fires or the enemy). If they're consistently inactive they may get a reduction in numbers, but I've never seen anyone seriously suggest to abolish the fire brigades.
Re: Efficiency is the enemy? (2021)
#36Earlier quoted context omitted.
Probably because that's pretty much the introductory chapter(s) (been a few years since I read it, but the topic comes up very early). Running everything at full capacity even when they can't do meaningful work for the sake of "efficiency" is a great way to accomplish a lot of wasted effort. It can go in several directions: 1. You have a lot of wasted work. You're making 100 widgets/hour that the next station can onl…
Isn't the example in your last paragraph more about specialization than cutting out slack? It seems to me like they misunderstood the value stream. The specialized added value by reducing the average administrative overhead of the engineers, which enabled the engineers to focus more on where they add the most value to the system. Not unlike the secretary and CEO in the article.
It's both, their specialization provided slack (both to themselves and the engineers). And yeah, the value stream was grossly misunderstood, and the work was undervalued.
Because of their specialization they were fast with broken systems (they used the same crappy web apps as us, but they understood them). Because they were not engineers and they got the work done fast, there was no perceived value in their role (classism and other biases at play here), it was thought (bad assumption) that the engineers could do it just as well themselves. And since the engineers had more than enough slack anyways, they could lose 15-30 minutes before and after a trip to dealing with the paperwork.
And if that assumption had been correct, maybe it would have been the right call. But the assumption was incorrect, and it was a very stupid call. We didn't charge the customers for that overhead, so any time the engineer spent on it (hours, sometimes days) was revenue lost. The dedicated team cost much less than the lost revenue so it was overall a net loss.
Re: Efficiency is the enemy? (2021)
#37Slack is great for resiliency, but it obviously can't be unbounded. The CEO in the article can't have 100 secretaries just in case. One of the great things about approaches like linear programming (programming in the sense of industrial engineering and not CS) is that it helps quantify how much that slack is worth. It can then be put into context of whether the risk tradeoff is worth the extra slack.
In a world where CEO time is apparently worth like 300X worker time, how many secretaries is the right number? I guess it is however many it takes to keep the CEO completely saturated with work...
Assuming salary maps to value add, let's say if the CEO is worth 300x the secretary, he needs 300 secretaries.
Re: Efficiency is the enemy? (2021)
#38Previously on hn: https://news.ycombinator.com/item?id=27036695
Re: Efficiency is the enemy? (2021)
#39The article's central illustration actually contradicts the claimed point. In the illustration, the secretary, Gloria, has slack, but the purpose her slack serves is not to enable change, which is basically what the article claims slack is for. Gloria's slack is just to make sure that Tony, the CEO, doesn't have any slack: he's working all the time on whatever he thinks is highest priority, and never takes a break. A…
> A much better example of the benefits of slack would be a CEO who delegates the day to day work ... to give himself slack -- more time to think about big picture things and consider ways to change the organization to make it better.
That's not slack. As you just pointed out, that's his regular job. Slack is unscheduled time, not time that's devoted to performing your duties. The point of slack, anywhere, is that it lets you respond to situations that arise, by converting the unscheduled time into time in which you respond. If you're fully scheduled, that's difficult to do.
Re: Efficiency is the enemy? (2021)
#40I wonder if this could be summarized as something like:
Efficiency is only useful until it imposes on some degree of slack, or spare resource, which allows you to respond to aberrations which (inherently fragile) efficient systems can't accommodate very well (Although you could argue that an efficient system would accommodate systemic aberrations well, but then I wonder if it would be a semantic argument).
Sort of like with finances. You could optimize your spending and investing as though economics are totally determinate, but they aren't, so you keep some cash as slack to accommodate cases where the shit hits the fan.
When working on a project, you could schedule your time down to the wire and work as hard/smart as possible to hit the deadline perfectly, but it's not going to work out well every time (or often at all in software). So you figure alright, it seems like something that should take 3 days, I'll bank on 5. If you come in over or under, it works out well for everyone. There is not point in trying to max out on efficiency in these cases.
In determinate environments where things really do work exactly as you'd expect, well, it's a different story. But human beings aren't that.