We've replaced secretaries with software, and now we have people making $150k+ a year busy working on things that they should be paying someone $40k a year to handle.
Efficiency Is the Enemy
31–40 of 335 posts
Re: Efficiency Is the Enemy
#32[deleted]
Re: Efficiency Is the Enemy
#33One of the quotes suggests that DeMarco (the author of the book under discussion in this post) himself views 'slack' somewhat negatively:
> “Slack represents operational capacity sacrificed in the interests of long-term health.” [emphasis mine]
Quibble it might be, but nevertheless: surely if the goal is to appreciate the value of 'slack,' it would be better to describe it as an investment in long-term health, rather than a sacrifice for it?
To be fair, I suspect he was trying to implicitly refer to "opportunity cost" - every investment implies a "sacrifice" of the alternatives. But it seems to lead the blog post author into a similar dissonant frame of thinking:
> Slack consists of excess resources... Slack is vital...
Here I quibble with the use of "excess." Excess compared to what? Presumably, excess compared to the resources one might assume were necessary to guarantee a healthy operation - but as the author then notes, these resources are not "excess" at all, but indeed "vital!" In other words, they are fundamental to the continued existence of the operation. Why imply anything else?
Re: Efficiency Is the Enemy
#34Some good food for thought in the article. You want enough slack time and energy to be able to accomplish the high priority items. You definitely want to avoid low ROI busy work.
But also beware the easy seduction of the idea that you don't have to work hard to have a good chance of success.
Re: Efficiency Is the Enemy
#35I've only been working professionally for 5 years and this is something I am only recently beginning to appreciate. Optimizing for efficiency makes you get a lot of work done but it reduces your ability to think creatively which can potentially impact the quality of ones work.
[deleted]
Re: Efficiency Is the Enemy
#36Counterpoint (kinda): https://efficiencyiseverything.com/
Re: Efficiency Is the Enemy
#37One of the quotes suggests that DeMarco (the author of the book under discussion in this post) himself views 'slack' somewhat negatively: > “Slack represents operational capacity sacrificed in the interests of long-term health.” [emphasis mine] Quibble it might be, but nevertheless: surely if the goal is to appreciate the value of 'slack,' it would be better to describe it as an investment in long-term health, rather…
>Excess compared to what?
I was reading this in the operations research sense of optimality. From this standpoint, they are excess in the current set of constraints but may be vital (an non-excessive) if those constraints change in the future.
Re: Efficiency Is the Enemy
#38Maximising utilisation usually means an increase in latency. You don't want your ambulances or fire fighters at high utilisation.
It's a balance. If 10 firefighters don't see high utilization, you don't want to increase the staff to 20, just in case. That's just a waste of money. The rule of thumb is that you want utilization to be where there is an acceptable latency depending on some percentile of cases. For a firefighter, you'd probably look at p99 latency. For a hamburger joint, p50 on order time would be good enough.
Seems like the original article/book and your comment tie back to Little's Law from queuing theory which is used as justification in Kanban for minimizing WIP.
Re: Efficiency Is the Enemy
#39In other words 99th percentile latency is what matters, not utilization. Anyone who's tried to get things done with batch-class resources has probably noticed this as well.
There's a similarity to the overall economy as well. Just in time inventory is certainly efficient but it's incredibly fragile. Just look at how much "damage" is being claimed for a boat that made other boats two weeks late.
Re: Efficiency Is the Enemy
#40The most famous book to discuss this idea is The Goal by Eliyahu Goldratt, published in the days when American manufacturing was trying to compete with Japanese methods. That book inspired The Phoenix Project by Gene Kim and others, which applied the ideas to DevOps.
It's been several years, so I don't remember how TPP tied slack to concrete DevOps practices. But in Google's SRE book (published by O'Reilly), they talk about how if more than half of an SRE's time is consumed by incident response, they push maintenance back to the developers. Reserving 50+% time for project work is a way to maintain slack. (See Time Management for System Administrators by Thomas Limoncelli for more techniques.)
(EDIT: I'm starting to remember more details from TPP now: One way to add slack is to find & remove bottlenecks, e.g. the sysadmin who was "too good" at solving everyone's problems. This is also why you may want to mix more generalists into your teams than is strictly efficient. Likewise with having "cross-functional teams". They can share work so there are fewer bottlenecks.)
In other software development, you can achieve slack by filling each sprint with a mix of high- and low-urgency work. (And btw, we should replace the word "sprint".) Or leaving 20% of your time for refactoring. Or practicing the Boy Scout method (and factoring it into your estimates). Or when the graybeards double any estimate before sharing it with the customer. Google's 20% time is another form of slack.
Webdev shops struggle with this since utilization is a major driver for profitability. I've seen many start in-house products to fill the time between client work. You'd think these would turn out great, since they are (or ought to be) experts at building and launching new tech ventures. But I've only seen a couple work out. In practice they get neglected as soon as more billable work arrives.
What works better is a focus on internal tooling. This is much like Toyota's continuous improvement (a connection also made in The Goal). You don't get continuous improvement unless you have slack, and it's a good way to "use" your slack. If you don't have any ideas for internal tooling (ha), maybe encourage your devs to make some open-source contributions.
It's notable that you don't achieve slack by sleeping in. The secretaries still had to show up to work, even if they didn't have too much to do. So you still need a good work ethic. This makes me skeptical of the author's idea that you can motivate yourself with tight deadlines. I often wait until the last minute to do things, but that's not really buying me slack.
On the other hand playing Counterstrike may be genuine slack, since you can always turn it off if something comes up. :-)
For developers, another way to use slack time, besides building tools and playing games, is personal development: read a book, do a course, write a blog post, etc. Your greatest asset is your mind, and you must invest in it! Or engage in a community and meet new people. That is a kind of investment too.
I suspect slack is better managed in the small than in the large. I'm thinking of Hayek's critique of central planning in Road to Serfdom, or Michael Polanyi's objection to centrally-planned scientific research. I knew a company once that devoted one in four sprints to refactoring. While that would be an improvement in many places, it feels a bit too centrally-planned to me. Give people slack, but let them use it how they like.