Outside developers often look at a large software company and think "that’s easy, I could build that in a weekend". This article describes why that’s misguided.
Reasons why are divided into two categories: technical and organizational. #Ankified
Technical: Large businesses find it profitable to do lots of optimization and build new features that are often more complex than outsiders realize. This requires hiring engineers. You want to keep hiring engineers until the marginal benefit of hiring 1 more engineer = marginal cost of hiring 1 more engineer. Companies that are smart do this math and often find they should hire many, many engineers.
Organizational: Large organizations have complex communication barriers that outsiders underestimate.
Notes
Technical Reasons you can’t "Build it in Weekend"
Hiring more engineers can improve site performance, which simultaneously increases revenue (there’s a wide body of research that’s found that decreasing [[latency]] has a roughly linear effect on revenue) while also reducing costs.
Engineers also help create features, and seemingly trivial [[features]] can add integer percentage points to revenue. Businesses should keep adding engineers to work on [[optimization]] until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin, which is often many engineers. #Hiring
[[features]] are often much more complex than outsiders realize. For a weekend [[MVP]], you can ignore things like [[internationalization]], but in a real business that would be ignoring a huge market.
Organizational Reasons you can’t "Build it in a Weekend"
Compared to [[organizational problems]], [[technical problems]] are straightforward.
[[Dan Luu]] uses the example of [[distributed systems]] to illustrate this
"Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they’re saying to what my coworkers think they’re saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years." #communication #[[communication issues]]
Successful organizations will inevitably grow and hire many staff, not because it’s necessary to run the service, but because they would be leaving money on the table if they didn’t.
This is related to a common fallacy in programming [[reliable systems]]: engineers build the happy path thinking that’s the “real” work, and [[error handling]] can be added later. For reliable systems, error handling is more work than the happy path. The same is true for big companies — everything people think isn’t “real” work is actually more work than the core service.