Wednesday, May 27, 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 comment:

  1. Let's say you've a leaking problem in a few floors of your building. You call an engineer to assess the situation and he'll start by saying something like this: "From my experience and from the assesment I've done at your building, there is a massive issue in X that can't be easily repaired. We have to bring down Y and redo it.. only then it'll stand Z, W, M, N for longs periods of time".

    Now your company needs to do web commerce or fix performance problems in the existing infrastructure... all IT can think of when they're called in is the word "easy" and how they'll be heros and show how they are smarter then everybody else. It's ego and childish feeling at play. All IT marketing centers around "easy" and "easy" often leeds to poor quality, quick jobs. But IT will try to cash in seeing you should pay a lot for a solution because it was "easy" and "quick".

    PS.: this is from someone in IT having to fight people offering "easy" and "quick" solution that will have the problems you describe in your post.