Hacker News new | ask | show | jobs
by dasil003 1735 days ago
This is well-stated, except one nuance: software is itself scalable, so small software teams can out perform large software teams if they can keep the requirements under control.

> A software engineer allowed to deep dive on a stream of tickets/tasks while being defended from non-software related issues by a manager is by far more efficient than one given the responsibility of "ownership."

This works if ownership boundaries are clear and unambiguous, however defining these boundaries involves many tradeoffs which may be judged incorrectly or shift over time. If so you may hear management start talking about "breaking down silos" and ICs enter a kafkaesque knightmare as the structure chokes on the communication overflow as no one is able to get the support from colleagues to get their own issues done because they are all assigned ownership of different issues.

Overall I think we need to be careful about naively optimizing for scalability and efficiency without first identifying the goal. Just as you probably wouldn't want Rickover designing enterprise software, you also don't want an OKR-toting MBA to be responsible for designing a nuclear submarine.

1 comments

You're thinking along the lines of the dimension of distribution. Yes in terms of distribution, software scales because it can be copied.

However there are many other dimensions of scalability to consider. Examine the complexity of the software system itself where thousands of people have to work on it. Eventually there will be no choice but to go this route due to rising complexity of the software. You need specialists with narrow assignments because those narrow assignments are already so complex that it takes a team to comprehend it. Engineers on these projects have to give up ownership of certain things and trust that others can handle it if they ever want to get any work done.

I stated it above as a tradeoff. Efficiency and scalability vs. flexibility. I completely agree with you on being careful about optimizing for scalability but eventually a bigger org HAS to make this tradeoff because they have no choice.

If a few bespoke nuclear submarines don't necessitate the trade off that's fine, but putting a new ever complexifying smart phone in the hands of the ENTIRE population year after year requires immense sacrifices to flexibility in the name of scalability.

Yes I understand all this, hence my comment about enterprise software.

My key point is that people fetishize scalability, IMHO because of individual incentives towards wealth and power. However in practice making something scalable often means making it horrible. "Leaders" who get paid by scope and headcount are incentivized to build big frankenstein projects that are fundamentally disjointed. This makes it very hard to fix problems that come up once the practitioners dig in, because the structure imposed from above already precludes a solution.

This isn't universal, certainly there are problems where it can be broken down cleanly by specialization, but it really depends on the interfaces and communication bandwidth/abstraction leakiness between the working groups.

Agreed. I'm not fetishizing scalability. I am saying that it is an inevitability.

If you can avoid it great, but if you continue growing. You must face it.