[miav]

As the top comment points out, the author comes off as arrogant and their view is unbalanced, but they do have a point.

I find the saying "What a programmer can do in a month, two programmers can do in two months" is quite true. I consider myself competent and the people I work with are even more so, but human communication is always very imprecise and slow. If you stack it into a hierarchy of teams and managers, efficiency loss becomes exponential.

I really do think that the best way to organize software development is to have discrete components with exactly one person in charge of a component. Of course there are notable downsides. If only one person is in charge of a component it would become quite opinionated and it would be difficult for devs to spot each other's errors, but I think it would be a great tradeoff nonetheless.

I really don't want to spend even 5 minutes of my life debating whether we should split a folder into 2 smaller folders or not. I'd much rather have any member of the team go with their gut on this. An individual's choice may not be as good as that of the entire group, but it's good enough.

[rrdharan]

This approach involves a high degree of risk, i.e. your bus factor is 1: https://en.m.wikipedia.org/wiki/Bus_factor

[miav]

Yes, absolutely. Having a single person do what they want with a component involves risks but I think they can be managed.

Say the dev in charge of an important component of a service is struck by a bus and dies. The optimistic scenario is that the code was well enough written that people developing adjacent components (ie. components that interface with that of the deceased dev) can effectively take over development in the short term until a new owner is found.

A more interesting scenario is that in which the dev abused autonomy and the component is utter spaghetti. In all but the most extreme of cases, the component could be kept in maintenance mode as is for some time. This would block progress that relies on changes in the component, but allow the service to continue working. In that time, other devs could either untangle the spaghetti and refactor the code into something workable or rewrite it. In both cases a significant amount of resources would be spent, but this is a scenario that's unlikely to occur often and the fact that the component was owned by a single person places a soft cap on the size of the component (and ideally an employee would maintain a couple of unrelated components to ensure they can continue working if one service is deprecated) ensuring it could be replaced within reasonable time.