>step on each others toes
Which leads us to a huge problem I’ve seen over the past few decades.
Too many developers for the task at hand. It’s easier for large companies to hire 100 developers with a lower bar that may or may not be a great fit than it is to hire 5 experts.
Then you have a 100 developers that you need to keep busy and not all of them can be busy 100% of the time because most people aren’t good at making their own impactful work. Then instead of trying to actually find naturally separate projects for some of them to do, you attempt to artificially break up your existing project in a way that 100 developers can work on together (and enforce those boundaries at through a network).
This artificial separation fixes some issues (merge conflicts, some deployment issues), but it causes others (everything is a distributed system now, multi stage and multi system deployments required for the smallest changes, massive infrastructure, added network latency everywhere).
That’s not to say that some problems aren’t really so big that you need a huge number of devs, but the vast majority aren’t.
> they don’t have to reinvent the wheel
Everything is a trade off, but we shouldn’t discount the cost of using generic solutions in place of bespoke ones.
Generic solutions are never going to be as good of a fit as something designed to do exactly what you need. Sometimes the tradeoff is worth it. Sometimes it’s isn’t. Like when you need to horizontally scale just to handle the overhead. Or when you have to maintain a fork of a complex system that does way more than you need.
It’s the same problem as hiring 100 generic devs instead of 5 experts. Sometimes worth it. Sometimes not.
There’s another issue here too. If not enough people are reinventing the wheel we get stuck in local optima.
The worst part is that not enough people spend enough time even thinking about these issues to make informed decisions regarding the tradeoffs they are making.