I was watching television last night when I had some random thoughts about my work. As you probably know from reading this blog, I run a small software company that specializes in rescuing projects that involved broken or underperforming software applications.
Today’s glut of hospital-based television shows often depict some surgeon valiantly trying to save a life, working for 12 hours at a time in a sterile, high-tech facility that includes a viewing gallery and CD system playing Mozart as the nurses and other assistants stand by to hand the surgeon tools, dap his brow, and provide enough suction to keep the work area clear.
Alternately, you have the style of surgery depicted on M.A.S.H. – the patient comes in all banged up, you zip him open, do the minimum amount of work required to repair the damage, and send him out. All this while running the hospital 3 nurses short, with a rapidly diminishing supply of blood and mortar shells going off near the camp’s perimeter, causing the lights to dim and flicker as the surgeon’s work. This is not-so-affectionately referred to as “meatball surgery”.
Being in the business of remediating software applications, I’d like to be able to say that it’s a lot like the first example, the clean, high-tech, sterile, orderly example. But it’s not. In fact, it’s not even close. Remediation is much more like M.A.S.H. – by the time the patient gets to your operating table, there is no time and no resource allocation to speak of – you’ve got to get in, work by your wits, and get out. All this with mortar shells going off and lights flickering. One of my consulting colleagues even jokingly refers to me as the Hawkeye Pierce of software development. I can only argue against that to a limited extent.
The term software remediation may sound as though I’m trying to put my own clever spin on the term “refactoring”. I’m not. Think of it this way – if refactoring is micro, remediation is macro. Remediation takes you all the way back to the original assumptions that went into making the design choices that led to the application being in a state that requires remediation. The word remediate literally means “to repair an oversight” or “repair a deficiency”. So, it bears a decent resemblance to what you see going on in television’s medical dramas – patient has a problem, surgeon must fix it, add drama, stir well, cook for 30 minutes, and you’re done.
I once read a tale of a fellow who had a tumor in his neck. It was thought to be a simple cut and close job, but once the surgeon went in he discovered that the tumor had strands wrapped around every major structure in the patients’ neck. What began as a simple excision turned into a 12-hour marathon of carefully cutting around healthy structures to remove the cancer in bits and pieces. You have to feel bad for that doctor – he probably had his day all planned out, and some pesky tumor threw a monkey wrench into his plans.
That reminds me of many of the projects my company takes on – more often than not, taking an application offline is absolutely not an option. We frequently have to redesign, refactor and retest in a live application because time and budgetary constraints dictate that creating a test environment is out of the question. Sometimes clients are literally losing money by the minute because of their broken software tools. On top of that, we are frequently working with clients that are hostile to developers in general because the guy that delivered the poorly-performing app we are fixing did so after going way over budget and way over the deadline, and as far as the client is concerned developers as a lot are bastards.
Obviously, this is not ideal. But it is often how the world works. Fixing broken software in the wild is a lot more like the resource-poor grit of M.A.S.H. than the yuppified plenty of Chicago Hope.
I’m doing my best to move my company away from this kind of remediation work. Too much stress, too little reward. To stick with the medical analogy, if I could go from M.A.S.H.-style remediation to, say, House-style remediation on a regular basis, that would be great. Dr. House at least has a little bit of time to whiteboard the problem before everything hits the fan and he has to do something, (even if it is wrong) because doing nothing would surely result in disaster. Most of the remediation projects I bring in now require us to hit the ground running.
In truth, I’ve had a few of those, where the application in question was broken but still usable (barely). It was nice. I rallied the team, spelled out the problems, reviewed some code, came up with a list of bottlenecks and problem points and formulated a plan of attack. I like that. Not totally planned, but not totally improvised either. A happy medium. House-style remediation sounds nice, I’ll have to try to get more of those projects. And truth be told, my demeanor is closer to Dr. House than Dr. Pierce. Alan Alda’s portrayal of Hawkeye Pierce is just so damned earnest, even at his worst – I am much more of an arrogant jackass.
Long story short, emergency medicine-style software projects no longer have any appeal for me. If I’m going to commit my team to a remediation project, it can’t be a total disaster the moment we walk in the door. I realize that I’m probably going to get a flood of email now from people asking me to look at their total wreck of a project, but please – don’t send those eMails. I don’t want those projects, and would have to be offered a lot of money to take another one on. In fact, I am tempted to remove the Software Remediation section from my site completely and offer it only as a "stealth service" to those that know to ask.
Paging Dr. House…