IT's time to stop blaming management
Enterprise systems do produce real, significant cost-savings by imposing standards and metrics on what was once chaos. But the result is inevitably software that’s inflexible and doesn’t grow well with the business. Enterprise software never ages well, it never evolves fast enough and it is always vulnerable to disruption — as you might expect of any system that adopts such a command-and-control, monolithic position with regard to its users.
I’ll repeat one bit for emphasis: …The result is inevitably software that’s inflexible and doesn’t grow well with the business. Enterprise software never ages well, it never evolves fast enough and it is always vulnerable to disruption — as you might expect of any system that adopts such a command-and-control, monolithic position with regard to its users.
Now let me ask: Should we expect this to apply to finished Enterprise Software Applications and not to the code produced inside Enterprises? I think it applies decisively to Enterprise Code Bases, and this isn’t something we can blame on Pointy-Haired Bosses.
When an “Enterprise Architect” drives a Platform, Framework, Tool, and Language “Strategy” that is all about Command and Control over the users of same platforms, frameworks, tools, and languages, you get exactly the same result
. And who uses these things? Developers. The moment your driving motivation is controlling developers and restricting what they do, you go down the exact same road and end up in the exact same place as when your driving motivation is command and control over users.
While some consider the slow rate of change of enterprise software to be a feature and not a bug this sort of logic isn’t very persuasive anymore and won’t fly far in the age of the web. The the web has clearly demonstrated that it’s possible to build a huge, stable, decentralized platform that still allow for all kinds of innovation without imposing undue restrictions on everybody and everything.
(Ironically the key ingredient may turn out to be trust, of all things, which is something any enterprises—being notoriously paranoid—are forever lacking.)
Software built with tools and policies that fight developers at every step is frighteningly difficult to change, it resists evolution tooth and nail. The argument that it has a lower Total Cost of Ownership in the long run is not just wrong, it turns out to be badly wrong: software developed by people in straight jackets is more expensive
to maintain, not less expensive.1
Centralization is a bug… Anything in the system that requires central authority, that’s something that holds you back.
I am not saying that Anarchy is a viable alternative to Bondage and Discipline. Lots of businesses fail from having too little structure, and software is no different than business in that respect. However, we see plenty of businesses that thrive by pushing decisions downwards, flattening their management structure, by motivating people to do the right thing, by making a commitment to quality staffing, and—yes, it’s true—by choosing to right-size their teams and resist the temptation to grow for growth’s sake.
There is no golden hammer, no silver bullet. It is hard for businesses to thrive and succeed in an environment of change, and it is hard for IT departments as well. But we have to wake up and smell the coffee. We can only blame “management” for so much, and then we have to turn our attention to our own practises, to the mistakes we
make that mirror the mistakes they
- Oh yeah? Where’s your study to prove it? Good question. I pulled that statement right out of my assets, to tell you the truth. Pure opinion based on the Appeal to Authority (20+ years of experience) and Confirmation Bias (successful projects) fallacies. I was going to pull that line, but I find it outrageous that tool vendors and their sycophants promote TCO as a benefit of their approaches without the slightest credible evidence backing it up.
Honestly, can anyone produce a study that shows business software written in Popular Language X has a lower TCO than business software written in Lisp? Or Python? Or ML? Or Ruby? Anyone? Anyone? The only things I can find when I look are obvious Blowhard Job studies by consulting groups funded by vendors.
Does anyone really know?
I have decided that I no longer accept such claims at face value. Not even my own.