(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Thursday, December 13, 2007
IT's time to stop blaming management
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.
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
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 make.
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.
—the aptly named blog discipline and punish
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.)
ibid.
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.
—Tim Bray, Message From the Web
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 make.
- 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.
Comments on “IT's time to stop blaming management”:
<< Home
Whenever I hear people talking TCO, especially as related to any one particular language/widget etc, my first response is siooma.. and then at least listen to the ones that stick around. With so many independent variables in any given situation, TCO talk is often no better than astrology.
# posted by 
: 8:46 PM
: 8:46 PM
"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."
This can actually give enterprise management a false sense of the direction. While we marvel at the successes of the online application diaspora, we fail to see thousands of failures. Producing a app that not only functions but is accessible is still the exception.
Most corporations would be unwilling to fund the effort the it took to turn the internet into an interactive playground.
This can actually give enterprise management a false sense of the direction. While we marvel at the successes of the online application diaspora, we fail to see thousands of failures. Producing a app that not only functions but is accessible is still the exception.
Most corporations would be unwilling to fund the effort the it took to turn the internet into an interactive playground.
# posted by : 8:41 AM
: 8:41 AM<< Home
