[HN Gopher] Advantages of incompetent management
___________________________________________________________________
Advantages of incompetent management
Author : zdw
Score : 115 points
Date : 2024-07-04 17:09 UTC (2 days ago)
(HTM) web link (yosefk.com)
(TXT) w3m dump (yosefk.com)
| advael wrote:
| I like this, and it seems a lot of people are thinking this way
| lately
|
| A common theme is that optimization usually does mostly bad
| things, while maybe arguably from someone's perspective doing one
| thing really well. I particularly like the example of the
| threshold cost to get something done versus the optimizer trying
| to lower costs. Both stakeholders in that example in actuality
| care about not going below the threshold, but the one drunk on
| optimization is incentivized to be at odds with keeping that cost
| center above it, let alone providing any cushion
|
| The model many people here likely have for optimization is
| compile-time optimizations, but that's actually a weird class of
| special cases where you actually can prove you're not breaking
| anything by doing so. Most optimization looks more like strip-
| mining. It leaves the structures it touches barren and brittle
|
| Most extant institutions have a desperate need to build better
| resistance to optimization-like objectives
| stoperaticless wrote:
| > It leaves the structures it touches barren and brittle
|
| If overdone - definitely.
|
| But there are plenty of cases where people forgot to add an
| index or used linked lists for search heavy stuff or issued rpc
| for every keystroke.
| abraae wrote:
| > Whatever objective you are expected to achieve, a bigger budget
| makes it easier.
|
| This should be true but I've seen bloated projects that would
| have had better outcomes had the team been more constrained.
|
| And to quote Fred Brooks:
|
| > There are many examples from other arts and crafts that lead
| one to believe that discipline is good for art. Indeed, an
| artist's aphorism asserts,'Form is liberating' The worst
| buildings are those whose budget was too great for the purposes
| to be served. Bach's creative output hardly seems to have been
| squelched by the necessity of producing a limited-form cantata
| each week. I am sure that the Stretch computer would have had a
| better architecture had it been more tightly constrained; the
| constraints imposed by the System/360 Model 30's budget were in
| my opinion entirely beneficial for the Model 75's architecture.
| yosefk wrote:
| Had Mr Brooks proven this belief in a revealed preference
| sense, by voluntarily shrinking his budget, it would add a lot
| of weight to what is otherwise a nicely sounding but not very
| believable passage. But I doubt that anyone could be so insane
| as to not trust _themselves_ with making a good use of a larger
| budget. One 's underlings - quite possibly!
| advael wrote:
| Also it's just so much easier to get the benefits of
| constraint without the downsides if one is in charge of the
| decisions. Like if you can do something with $10k and have
| $30k to work with, many adults manage to constrain themselves
| by merely moving $20k to a savings account, and those who
| lack the requisite executive function for this simple "out of
| sight out of mind" organizational schema can often function
| with slightly stronger artificial constraints, sometimes
| aided by a collaborator. People do NaNoWriMo or whatever, and
| while many fail, the benefit of the artificial time
| constraint motivates a lot of people, despite being self-
| imposed. In either case, this informal method of constraint
| is more responsive to situational changes or emergencies than
| an optimization valve that always wants to bring costs down
| and doesn't understand any of the functional constraints, as
| is the case for most finance and management arms of
| "efficiency"-driven orgs. The game theory of budget inflation
| is really obvious when you consider it in terms of locus of
| agency
| calihispdtrn wrote:
| California high speed train to nowhere comes to mind. Billions
| and billions and billions of dollars lost to graft and waste.
| Indeed, as government budgets increase they become less
| effective.
| com2kid wrote:
| The comments on resource utilization are one of those things that
| is only true now that there is a 1:1 correlation between $ and
| available CPU/Memory, and the pool of available CPU/Memory
| resources is effectively unlimited.
|
| Embedded is maybe the last refuge of where there are hard
| resource constraints that cannot be violated. If you only have
| 64K of RAM, you had better make it work!
|
| IMHO this is why you can end up with embedded code that is easily
| 10x to 100x more optimized than code running in other
| environments. It is also, why IMHO, the user experience on Smart
| Phones doesn't improve linearly with the hardware improvements -
| see https://en.wikipedia.org/wiki/Wirth%27s_law
|
| This train of thought, along with basically flatlined GPU
| performance / $, explains also why we are seeing real algorithmic
| improvements in the ML/AI space. If we were still operating under
| Moore's law and GPUs and VRAM were 2xing every couple of years, I
| doubt we'd see all the research efforts going into optimizing
| training, fine tuning, context windows, inference, and so forth.
| yosefk wrote:
| TFA author - I have worked on low-cost embedded systems.
| (Tens/hundreds of megs of RAM, not KBs.) The only case where
| you don't hoard resources is if the system is so small that
| it's programmed by a small team since the functionality is
| severely limited by resource scarcity, so there's no reason to
| grow the team to deploy more functionality. Above a certain
| not-so-large size, people will hoard resources in an embedded
| system - they can't ask for more capacity like they would if it
| was server-side software, but they sure can avoid giving up
| whatever resources their code is already using.
|
| Researchers actually have a limited and smallish hardware
| budget, so academia is likely to come up with cost-saving ideas
| even when hardware performance grows very quickly. In the
| industry you can throw more hardware at the problem even if
| it's not improving (outside embedded/client devices)
| yummypaint wrote:
| _Things work the same with any resource, not just actual money -
| it could be team size, or processor cycles and memory bytes. If
| you free up 200 ms of CPU cycles and 500 megs of RAM, someone
| else can deploy their functionality using these newly available
| resources, and then you won't be able to. In fact, a mature,
| well-run CI system will measure everyone's resource footprint
| after each commit, and will not let you exceed your budget, which
| was frozen at some point based on how much you were using at the
| time (hope it was a lot! - always spend like crazy before the
| baseline is established!) Is it any wonder that people learn to
| never optimize their code - unless they want to deploy something
| new themselves, and only after asking for more resources to
| deploy it and not getting any?_
|
| This explains so much. It also sounds like broken water laws in
| the western US that incentivise farmers to intentionally waste
| water to preserve their future ability to waste water.
| darkhorn wrote:
| During Covid European planes were flying to keep their slots
| https://www.theguardian.com/environment/2022/jan/26/airlines...
|
| Another one is to keep communication satalite slotes. If you
| loose a slot another country can claim your orbit.
| apantel wrote:
| Coordination between more than one developer is the root of all
| evil.
| throwup238 wrote:
| This is what Knuth actually said:
|
| _> We should forget about our coworkers, say about 97% of
| the time: premature coordination is the root of all evil. Yet
| we should not pass up our opportunities in that critical 3%
| to take credit for their work._
| vbezhenar wrote:
| Why does it happen? My CI launches separate kubernetes pod for
| every incoming task. If there are not enough servers,
| autoscaler will spin up new and remove it after some time. So
| there are not much expenses, we're paying for what we using. I
| feel that fast CI iterations are very important for developers.
| JackSlateur wrote:
| On the other hand, money is not free: many poor souls worked
| their ass off to pay for our toys. Putting their work in good use
| is the least of respect.
| metadat wrote:
| I found this piece highly informative, and I like the way the
| author's mind works, along with the playful presentation. This
| reminded me of "The Gervais Principle: The Sociopaths, The
| Clueless, and the Losers".
|
| https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
|
| Discussed here 15 (!) years ago:
| https://news.ycombinator.com/item?id=881296
|
| @yosefk or anyone else- do you have suggested related reading?
| matrix87 wrote:
| > Bug fixes work a lot like efficiency improvements, the main
| difference being that competent management makes things much
| worse. You can't make fixing bugs into a "goal," same as you
| can't make optimization into a goal, because people will just add
| more bugs up front and then fix some of them.
|
| If competent management makes things worse, then it isn't really
| competent management. I'm not sure why introducing additional
| process is considered a sign of competence
|
| Instead of setting arbitrary goals, couldn't they just pay
| attention to the things that people are actually working on and
| give out rewards/punishments based off of their own judgement? If
| you need to create some elaborate resource quota CI/CD system
| because you can't trust employees to do things decently, then
| it's a people problem
|
| There's a false equivalence that's presented here: either have
| some impersonal bureaucratic process in place, or don't do
| anything at all. Why is actually talking to employees about what
| they're working on not suggested as an option?
| agumonkey wrote:
| I'm on the first part and I struggle to not scream.
|
| - the well run place seems too keen on micro managing. Estimating
| every step to the point of cancelling improvement is not 'well
| run'. I'm sure every book about advanced company management will
| tell you that.
|
| - the badly run is hmm.. at least partially (if not totally)
| naive. What are the odds that people not being asked anything
| don't just talk all day long ? The most probable equilibrium
| point will be most employees doing a little bit of the mandatory
| duties in the morning, a little bit in the afternoon, separated
| by lengthy bits of smalltalk (not they kay kind). I have yet to
| see one person trying to fix anything in their environment
| because they had free time. 99% of them will just have a new
| topic to vent about in the coming coffee / smalltalk pause.
|
| ps: anybody knows talks or books about people operating like
| emergency teams ? where the natural spirit is optimize everything
| until you reach hard limits ?
| bwestergard wrote:
| A very similar thesis was put forward by Galbraith in "The New
| Industrial State".
| fsndz wrote:
| competent management should add flexibility to rigid goal
| setting.
| YZF wrote:
| Creo (based in Vancouver, BC) used to be a company that tried to
| address this. The concept that was used was called "unit
| presidency". Each employee was empowered, expected, and trained,
| to make decisions as if _they_ are the president of the company.
| The principles behind making decisions were called "economic
| thinking" which the CEO used to say was everything he learnt in a
| Harvard (EDIT: or maybe it was Stanford) MBA distilled into the
| core principles. Basically looking at the ROI (Return on
| Investment) of the decision. Decisions were generally made by
| consensus though depending on the nature of the decision
| sometimes other methods were used. This extended to decisions
| that involved spending money, not just should you pick language X
| or language Y for your next software project.
|
| I think it worked pretty well for quite a few years. It gradually
| stopped working when the company acquired a large company with a
| different culture and also hired people (well, managers mostly)
| who weren't aligned with the culture. Eventually this basically
| disappeared when the company was acquired by Kodak.
|
| I've seen flavors of this in other places. Famously Andy Grove of
| Intel also preached that decisions need to be made by those
| closest to the decision and empowered people to make the right
| decisions. More generally this can be reflected in a servant-
| leadership model where leadership sees itself as facilitating the
| growth of the people underneath them.
|
| Another requirement for this to work well is that management
| (e.g. the CEO or other leaders) are able to lay down a broad
| strategy for the people of the company to execute on. If the
| leadership has no strategy then tactical decisions can not be
| made properly. They also need to make sure there's coordination
| and structure.
| Spooky23 wrote:
| [delayed]
___________________________________________________________________
(page generated 2024-07-06 23:00 UTC)