←back to thread

Understanding how bureaucracy develops

(dhruvmethi.substack.com)
192 points dhruvmethi | 7 comments | | HN request time: 0.002s | source | bottom
Show context
sevensor ◴[] No.41889622[source]
When you treat every negative outcome as a system failure, the answer is more systems. This is the cost of a blameless culture. There are places where that’s the right answer, especially where a skilled operator is required to operate in an environment beyond their control and deal with emergent problems in short order. Aviation, surgery. Different situations where the cost of failure is lower can afford to operate without the cost of bureaucratic compliance, but often they don’t even nudge the slider towards personal responsibility and it stays at “fully blameless.”
replies(13): >>41890119 #>>41890303 #>>41890339 #>>41890571 #>>41891032 #>>41891181 #>>41891213 #>>41891385 #>>41891417 #>>41893574 #>>41894181 #>>41897147 #>>41903458 #
SupremumLimit ◴[] No.41890339[source]
This is a wonderfully insightful comment!

I’ve encountered a similar phenomenon with regard to skill as well: people want to ensure that every part of the software system can be understood and operated by the least skilled members of the team (meaning completely inexperienced people).

But similarly to personal responsibility, it’s worth asking what the costs of that approach are, and why it is that we shouldn’t have either baseline expectations of skill or shouldn’t expect that some parts of the software system require higher levels of expertise.

replies(2): >>41890960 #>>41891632 #
jiggawatts ◴[] No.41890960[source]
There is the reason Haskell or F# are relatively unpopular and Go has a much wider footprint in the industry: high expertise levels don’t scale. You can hire 100 juniors but not 100 seniors all trained up in the same difficult abstractions.

Conversely, one skilled senior can often outperform a hundred juniors using simpler tools, but management just doesn’t see it that way.

replies(2): >>41891423 #>>41893615 #
1. jjav ◴[] No.41893615[source]
> Conversely, one skilled senior can often outperform a hundred juniors using simpler tools, but management just doesn’t see it that way.

Management is correct, if that's the question.

In some very rare bleeding edge cases it is true. Everyone wants to think their company is working on those areas. But here's the truth: your company (for any "you") is actually not.

If you're writing code that is inventing new techniques and pushing the hardware to limits not before imagined (say, like John Carmack) then yes, a single superstar is going to outperform a hundred juniors who simply won't be able to do it, ever.

Asymptotically close to 100% of software jobs are not like that (unfortunately). They're just applying common patterns and libraries to run of the mill product needs. A superstar can outperform maybe 3-4 juniors but that's about it. The jobs isn't that hard and there are only so many hours in a day.

This is made worse today because neither quality nor performance matter anymore (which is depressing, but true). It used to be the software had to work fast enough on normal hardware and if it had bugs it meant shipping new media to all customers which was expensive. So quality and performance mattered. Today companies test everything in production and are continuously pushing updates and performance doesn't matter because you just spin up 50 more instances in AWS if one won't do (let the CFO worry about the AWS bill).

replies(2): >>41894776 #>>41894867 #
2. aleph_minus_one ◴[] No.41894776[source]
> A superstar can outperform maybe 3-4 juniors but that's about it. The jobs isn't that hard and there are only so many hours in a day.

There do exist (I would even claim "quite some") jobs/programming tasks where superstars are capable of, but a junir developer will at least need years of training to be able so do/solve them (think, for example, of turning a deep theoretical breakthrough in (constructive) mathematics into a computer program; or think of programming involving deep, obscure x86 firmware trivia), but I agree with your other judgement that such programming tasks are not very common in industry.

replies(1): >>41895343 #
3. fcatalan ◴[] No.41894867[source]
Programming doesn't happen in a vacuum, and experience and institutional knowledge can account for many orders of magnitude of performance. A trivial example/recent anecdote:

The other day, two of our juniors came to see me, they had been stumped by the wrong result of a very complex query for 2 hours. I didn´t event look at the query, just scrolled down the results for 10 seconds and instantly knew exactly what was wrong. This is not because I'm better at SQL than them or a Carmack level talent. This is because I've known the people in the results listing for basically all my life, so I instantly knew who didn´t belong there and very probably why he was being wrongly selected.

Trivial, but 10 seconds vs. 4 man hours is quite the improvement.

replies(1): >>41898071 #
4. ifyoubuildit ◴[] No.41895343[source]
You don't even need to go to rocket science for this.

3-10 juniors can make a massive expensive mess of a crud app that costs $x0k a month in amazon spend and barely works, while someone who knows what they're doing could cobble it together on a lamp stack running under their desk for basically nothing.

Knowledge/skills/experience/ can have massive impact.

replies(1): >>41897117 #
5. jjav ◴[] No.41897117{3}[source]
> 3-10 juniors can make a massive expensive mess of a crud app that costs $x0k a month in amazon spend and barely works, while someone who knows what they're doing could cobble it together on a lamp stack running under their desk for basically nothing.

Yes! Absolutely. It will be faster and more reliable and an order of magnitude (or more) cheaper.

Alas, I'm slowly (grudginly and very slowly) coming to terms accepting that absolutely nobody cares. Companies are happy to pay AWS 100K/mo for that ball of gum that becomes unresponsive four times a day, rather than pay for one expert to build a good system.

6. jjav ◴[] No.41898071[source]
> Trivial, but 10 seconds vs. 4 man hours is quite the improvement.

Sure. But now try sustaining that impact multiplier every minute, 8 hours a day for a year.

replies(1): >>41903576 #
7. potato3732842 ◴[] No.41903576{3}[source]
That's a red herring. It's a question of how open that multiple has to show up to make one approach or the other the winner.