5 ms·

All the larger projects I've worked with were designed initially so you add/remove "programming resources" as needed. "Simple" languages such as Java SE and JUn

All the larger projects I've worked with were designed initially so you add/remove "programming resources" as needed. "Simple" languages such as Java SE and JUnit were heavily used to enable that. Over time some people still found ways to make themselves indispensible. When such people left, it was much harder to replace a single component that they maintained, but in the end it was possible either by refactoring, virtualizing or even copy-pasta. For better or worse all successful software projects that I worked with did better where no one was irreplaceable. No one truly is, but when they put themselves in that 'hero' position, it means they can't take the weekend off when it's deployment time or they need to deal with support cases personally and they burn out. And then it hurts the project more compared to an average contributor burning out. To sum up - project managers will tend to organise software so it's more of a commodity, programmers will try to do the inverse. Software being more of a commodity is usually better for the project and worse for the programmer and vice versa, at least in the short and medium term.

kpil 10y ago
There is two sides on this coin. Nothing beats software craftsmanship combined with domain expertise. That is what makes the impossible possible. The developers that have these skills are not a commodity. The scenario that you describe is not uncommon. It is a cultural problem, where there is no information sharing and developers "own" the code, even within a team. On the other hand, sometimes, especially in larger organisations, there are too many C-level developers and that will burn out or drive away any A- and B-level developers. The initial symptoms in the latter case is similar, with hero-developers and personal dependencies, but the difference is that the productivity slowly grinds to a halt as the code grows by copy-paste into a huge tangle of fragile code and bugs. In these kind of organisations, programming is probably also treated as a commodity.

kpil 10y ago

There is two sides on this coin. Nothing beats software craftsmanship combined with domain expertise. That is what makes the impossible possible. The developers that have these skills are not a commodity. The scenario that you describe is not uncommon. It is a cultural problem, where there is no information sharing and developers "own" the code, even within a team. On the other hand, sometimes, especially in larger organisations, there are too many C-level developers and that will burn out or drive away any A- and B-level developers. The initial symptoms in the latter case is similar, with hero-developers and personal dependencies, but the difference is that the productivity slowly grinds to a halt as the code grows by copy-paste into a huge tangle of fragile code and bugs. In these kind of organisations, programming is probably also treated as a commodity.