raganwald
Thursday, December 13, 2007
  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.
—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.



  1. 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:
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.
 
"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.
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /