I'll take advantage of the fact that you commented here to point out something unrelated that I found concerning in the article's reasoning:
"""
Companies that have..
A team that defines the standards, processes, practices, frameworks or architectures that other teams must follow.
...are amongst the lowest performers. Reversed: companies that lack this, amongst the high performers.
In other words: enforced standardising the tech, doesn't pay off.
This makes sense: if everyone in a company is forced to use, say, Django, for any project, regardless, there will be a lot of projects where Django is a very poor choice.
"""
I think that's not too far from presuming you should put armour where you find the most bullet holes in the planes that come back.
You have to keep in mind that an implicit trait of all of these companies is that they are still in business, despite having a "low" ranking for the evolution of their tech team. That speaks volumes about what it takes for their business to succeed, and apparently it isn't investing in a high quality technology team. Despite that, they've survived, and it's entirely possible that having "a team defining standards, processes, practices, frameworks or architectures that other teams must follow" is the trick that's staved off their otherwise higher propensity for existential disasters.
Of course, that's presuming there's any kind of causal relationship between having such a team and outcomes. In reality, the survey found that 16% of "low" companies had such a team, but 10% of mid and 7% of high companies also did. That's as compared to 15% of "low" companies that had a team that responds to tickets related to infrastructure issues, whereas only 6% of mid-level and 5% of high level issues... or the even bigger discriminant of a team that provides software delivery solutions for many feature teams through self-service APIs, which made up 3% of low teams, but 15% of mid-level teams and 23% of high-level teams. In that context, maybe having a team that defines standards & practices really is driven by factors that at best correlate somewhat with how evolved your tech team is.
...and I think one could argue much the same thing about frameworks, for much the same reason.
Realistically, having a team defining standards & practices doesn't actually play out as "if everyone in a company is forced to use, say, Django, for any project, regardless, there will be a lot of projects where Django is a very poor choice." The entire job of centralized teams like that is not to make everyone use one technology for everything, but rather to allow teams to operate independently while avoiding all the inefficiencies that come from teams using different tools that don't actually add much value but certainly subtract value. Take the case of choosing Django. If you don't need anything like Django, of course you shouldn't be using it. That's not what standards are intended for. What they are intended for is cases where using Django may be a perfectly fine tool for what your team is doing, BUT if you used Flask instead it really wouldn't matter that much. There might be a whole ton of other teams using Flask, a lot of tribal knowledge about how to operate it, and a ton of tooling that's already been integrated with it. While it might be better to use Django for your specific project (more often than not, that's not actually the case), in aggregate for the organization, it's way better if you just use the same technology as everyone else... and where things go organizationally overall in the long run is far worse, because with everyone using different technologies and no consideration for how they all interoperate together, you have no common fabric you can plug in to effect systemic change.
> What they are intended for is cases where using Django may be a perfectly fine tool for what your team is doing, BUT if you used Flask instead it really wouldn't matter that much
This is a good summary of my entire article, really. What I said is that on one axis, frameworks are a very bad trade-offs. There always are trade-offs. The axis being "maintainability".
That does not mean one should always avoid frameworks. Nor does it mean that without a framework, software magically turns maintainable. But it does mean that the benefits a framework bring, come at a cost. Make the tradeoff, weigh the cons and pros, and then decide if a framework, company-wide standardisation, team-knowledge etc. weigh up to the downsides of that framework. One of which being that it puts limitations on how well maintainable you can shape the software.
> But it does mean that the benefits a framework bring, come at a cost.
Except they don't really, right? Sure, there can be some negatives, but those negatives, are by and large coming anyway. If you had a rule that you don't use any outside tooling, that outcome is invariably far, far worse.
""" Companies that have..
...are amongst the lowest performers. Reversed: companies that lack this, amongst the high performers.In other words: enforced standardising the tech, doesn't pay off.
This makes sense: if everyone in a company is forced to use, say, Django, for any project, regardless, there will be a lot of projects where Django is a very poor choice. """
I think that's not too far from presuming you should put armour where you find the most bullet holes in the planes that come back.
You have to keep in mind that an implicit trait of all of these companies is that they are still in business, despite having a "low" ranking for the evolution of their tech team. That speaks volumes about what it takes for their business to succeed, and apparently it isn't investing in a high quality technology team. Despite that, they've survived, and it's entirely possible that having "a team defining standards, processes, practices, frameworks or architectures that other teams must follow" is the trick that's staved off their otherwise higher propensity for existential disasters.
Of course, that's presuming there's any kind of causal relationship between having such a team and outcomes. In reality, the survey found that 16% of "low" companies had such a team, but 10% of mid and 7% of high companies also did. That's as compared to 15% of "low" companies that had a team that responds to tickets related to infrastructure issues, whereas only 6% of mid-level and 5% of high level issues... or the even bigger discriminant of a team that provides software delivery solutions for many feature teams through self-service APIs, which made up 3% of low teams, but 15% of mid-level teams and 23% of high-level teams. In that context, maybe having a team that defines standards & practices really is driven by factors that at best correlate somewhat with how evolved your tech team is.
...and I think one could argue much the same thing about frameworks, for much the same reason.
Realistically, having a team defining standards & practices doesn't actually play out as "if everyone in a company is forced to use, say, Django, for any project, regardless, there will be a lot of projects where Django is a very poor choice." The entire job of centralized teams like that is not to make everyone use one technology for everything, but rather to allow teams to operate independently while avoiding all the inefficiencies that come from teams using different tools that don't actually add much value but certainly subtract value. Take the case of choosing Django. If you don't need anything like Django, of course you shouldn't be using it. That's not what standards are intended for. What they are intended for is cases where using Django may be a perfectly fine tool for what your team is doing, BUT if you used Flask instead it really wouldn't matter that much. There might be a whole ton of other teams using Flask, a lot of tribal knowledge about how to operate it, and a ton of tooling that's already been integrated with it. While it might be better to use Django for your specific project (more often than not, that's not actually the case), in aggregate for the organization, it's way better if you just use the same technology as everyone else... and where things go organizationally overall in the long run is far worse, because with everyone using different technologies and no consideration for how they all interoperate together, you have no common fabric you can plug in to effect systemic change.