Tuesday, October 11, 2011

A smoothly operating, well-oiled engine for failure

It occurs to me that much of "Big IT" creates a well-oiled organization that makes broken software seem acceptable. The breakage is wrapped in layers of finely-tuned process.

Consider a typical Enterprise Application.  There's a help desk, ticket tracking, a user support organization that does "ad-hoc" processing, and a development organization to handle bug fixes and enhancement requests.  All those people doing all that work.

Why?

If people need all that support, then the application is -- from a simplistic view -- broken.

The organization, however, has coped with the broken application by wrapping it in layers of people, process, tools, technology, management and funding.  The end users have a problem, they call the help desk, and the machine kicks in to resolve their problem.

It is a given -- a going-in assumption -- a normal, standard expectation that any enterprise software is so broken that a huge organization will be essential for pressing forward.  It is expected that good software cannot be built.

We're asked to help a client create a sophisticated plan for the New Enterprise App support organization.  Planning this organization feels like planning for various kinds of known, predicted, expected failures. Failure is the expectation.  Broken is the standard operating mode.

Consider a typical non-Enterprise Application.  Let's say, the GNU C compiler.  Or Python.  Or Linux.  An almost entirely volunteer organization, no help desk, no trouble tickets, no elaborate support organization plan.  Yet.  These products actually work flawlessly.  They're not wrapped in a giant organization.

Why is the bar for acceptability so low for "Enterprise" applications?  Why is this tolerated?