Monday, May 4, 2009

Your Application is a Rotting Old Shack, Now What?

In response to A Shack in the Woods, Crumbling at the Core, colleague Jim Graves commented:
“…it only works if application owners are like long-term homeowners, not house flippers.”
Shack-Jason_PrattGood point. Who cares if the shack gets a cheap paint job instead of a foundation and a comprehensive re-modeling? Will the business owner know or care? Do the contractors you hired care? Are you going to be around long enough to care? Are you and your employees, managers and consultants acting as house job flippers, painting over the flaws so you can update your resumes, take the profits and move on?

Jim asks:
“Are long-term employees more likely to care about problems that may happen five years from now? Are Highly Paid Consultants much less likely to?” 
Good question. Suppose that I want to fix the shack. Maybe I’m tired of having to empty the buckets that catch the drips from the roof (or restart the J2EE app that runs itself out of database connections a couple times a week). If this repair is to be anything other than a paint-over, at least one element in the business owner-->employee-->consultant-->contractor chain will have to care enough about the application to ensure that the remodeling is oriented toward long term structural repairs and not just a paint-over. The other elements in the chain need to concur.

For much of what I host and/or manage, I’m on the second or third remodeling cycle. I’ve seen the consultants parachute in, slap a coat of paint on the turd and walk off with a half decade of my salary. I don’t like it. This puts me squarely in the camp of putting the effort into fixing foundations instead of slapping on paint and shingles. I’ve seen apps that have been around for ten years and two refresh cycles, have had ten million dollars spent on them and still have mold, rot and leaks from a decade ago. But they have a shiny new skin and state of the art UI. For wireframes, UI models, usability studies and really nice Power Points? Spare no expense. Do they have a sane data model and even trivial application security? Not even close. Granite countertops are in scope, fixing the foundation is out of scope.

Things like that make me crabby.

For now I’ll assume that the blame lies with IT. Somewhere along the line the non-technical business owners have been led to believe that the shiny face and the UI is the application, and that the foundational elements (back end code, databases, servers, networks and security) are invisible, unimportant, or otherwise non-essential.


  1. Forget the issue that foundations are not sexy.

    The real issue is: foundations are not visible.

    The business owner sees a need for PowerPoint. Problem: I can't get power point out of this app. Solution: find someone to put that function in.

    The business owner never sees the foundation. Even if he is given a detailed, personal tour of the foundations.

    The business owner sees Problem: my IT guys are complaining about some data integrity architecture thing again, dunno what; they say it will cost a fortune to fix though. Solution: I don't have a fortune. Problem solved!

    The business owner sees things working. Maybe things crash occasionally, but isn't why he pays those IT guys -- to handle that? Maybe things run slowly, but hey they work well enough, don't they? Pretty good for ten-year-old technology, too.

    And besides, now we can get PowerPoint out of it.

  2. Excellent observations. I couldn't agree more.

    Unfortunately I don't know how to fix it either.

  3. There's also the risk and ROI elements. The shiny coat of paint comes with a promise that more people will buy widgets from the web site.

    This is not properly weighed against the 1% risk that the entire customer database will be lost due to infrastructure issues. Cost is too high, level of service is good enough. And I'm already paying you people to be here every day to monitor and fix things which break.

    Last time we did a migration, I campaigned with the service management for us to build in more automation and instrumentation to help Ops. The migration PM didn't want to change his plan/budget but the service people got their non-functional requirements put into scope, so it happened.

    Nice set of posts/articles by the way, I'm enjoying reading them.