> Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.
It seems like you're implying that teams of 60-80 developers should be expected to outperform teams of 12. This is simply not true. The most important feature of source code as a language is that it allows precise mindshare among close knit teams. It doesn't guarantee it, but it makes it possible for people to talk about the product at a level that is otherwise very difficult.
A convenient side-effect of the source code is that it instructs the machine what to do. But instructing the machine was never the bottleneck, the essential difficulty of software development is in understanding what are the correct instructions to achieve some objective, not typing them out.
The problem is that communication doesn't scale at all. Having just 3 developers with good alignment about mental models, best practices, and design direction is hard enough, and if you found the right three people at the right time with the right ideas, you could generate billions of dollars of value.
Large monolithic teams on the order of 80 are a product of people in control not understanding how software development works, and how to make it work well.
My expectation is that the toolchain will expand by another order of magnitude because LLM's, not just because of what they can produce, but because we are lowering the ceiling with LLM assistance when it comes to just understanding the toolchain. That creates a vacuum that people can fill up with more stuff.
The "insanity" that makes people do this is hard to explain. It's certainly irrational and seemingly unconscious.
That's awesome
I would much prefer to have coworkers that literally commit zero code than the monkeys I sometimes work with who commit way too much code, or just plain commit the wrong code
We've managed to emulate this behaviour in silicon now.
In fact, the entire tech sector, favouring fresh grads out of college over greybeards, is built this way. My pet very controversial theory is that this phenomenon is massively fueled by everybody and their dog using ADHD stimulant medication to get through their day; fresh grads + amphetamines is the preceding step to Kubernetes and the entire React ecosystem.
tl;dr: modern software is built by 'work hard, not smart' kinda types.
I was recently chatting with a friend about how we used to do so much more with so few developers: 20 years ago, we developed mission critical, real time software (trading systems) in C++ with team of a couple of dozen developers. The core trading kernel team was four people. An in-house distributed process orchestration tool (both front end and back end written in C++) were two guys. I myself once managed to produce an entire post-trade risk management system for futures contracts in a couple of months, working alone. Today, I see teams of 60-80 working on web and mobile applications where the vast majority of operations are CRUD, with some transaction/queue complexity at the extremities.
I think the difference is tech churn. Back then, what few dependencies we had in terms of either runtime libraries or development time tools, were stable: the standard library, compiler, unix commands and bash scripts, and some internal libraries. Much of our time and focus went into figuring out the right algorithms and data structures, with coding coming in second. Very little time was spent on selecting, configuring, updating, rearchitecting or replacing tech stacks and tools.