An excerpt from “Band-Aids and Broken Arms,” by Daniel Pasco<br/> Image courtesy of Andrei Cristea

When the client approached us, he described the work as fairly routine. The work he wanted sounded very doable, so I told him that we’d be interested in taking on the project. I told him what our standard hourly rate was and he blanched and told me that this was substantially higher than what they typically paid.

I wasn’t too surprised, for routine development there are definitely cheaper alternatives than going with us.

He said that he might be able to pay a figure that was almost half of what I’d quoted him and said that it would be considerably higher than anything that they’d paid before. He told me that most of the work had been for $20/hour, and that they’d paid one contractor $30/hour. He then went on to say that they might be able to pay us a little more because they’d also like to get the code “cleaned up a little bit.”

At this point, a little voice in the back of my head said “Uh oh, this sounds familiar.”

The story he went on to tell was one I have heard far too often. The entire website and purchasing system had been kludged together over the years by several different developers, each offering cheap work and a promise to fix the system. At one point the company had acquired another business and had attempted to merge the two websites, again enlisting the services of the lowest bidder.

Various individuals had been hired on the cheap to try and fix the system. Most of them worked on it for awhile, took some money, and then left the manager with a site somewhat more unstable than it had been before.

I asked if there were any documents describing the architecture. No.

I asked if there was anyone that could provide me with an overview of the architecture. No, but there were a few people that administered the system that might be able to tell me a little more about it than he could.

I asked if they had a testbed that we could use for testing out new code. No, they didn’t have one, hey, that sounded like a pretty good idea though, if they could afford it.

A little reserach revealed the truth: the system wasn’t just a mess, it was an inoperable mess. Several different developers had gone in and worked on the code base, and the system was a mess of dead code, bad code, and redundant code. A few tentative efforts to make even the simplest changes had bizarre, unpredictable results. And since this work was being done on the production system, any thing that broke the web site (uh, “broke it more”) would become a highly public, expensive PR disaster.

What they had was a broken arm, and they were hoping that a band-aid would be enough to fix their problem.

The site needed what it should have had in the first place, a real architecture, an actual testbed, and a team of people that actually knew what they were doing. Realistically speaking, a complete re-write from the ground up was the only sane way to go. Trying to come in cold, get up to speed on the current “design” and refactor it into something that would work and be maintainable would take about as long and have a substantially lower chance of success.

Screwed
They had problems, but if we agreed to take on the work, we’d be screwed. There was no way I could take on this job with a clear conscience. Since the customer was already coming at this from the mindset of “let’s get this done as quickly and cheaply as possible” there was no way that they would accept the idea of paying for a full re-implementation. The very best we could hope for from them was a green light to try and make the broken system work in one or two months (which was hopeless) for about half of our usual pay rate. We would be doomed to fail before we even started the work.

We’d be taking responsibility for making it work, at a losing payrate, with no hope of success. Taking on the project would tie up our guys, limit our income, and embroil us in trying to save a project that was doomed to fail.

I was fairly sure of the outcome, but decided that the manager deserved to hear my recommendation: pony up the green and start from scratch. Get a real architecture and a real testbed, and do the job they should have done four years ago instead of trying to get by as cheaply as possible.

Needless to say, he declined, and we went our separate ways.

You really DO get what you pay for
The real irony here was that the decision to do things as cheaply as possible had ended up costing them considerably more than they’d saved in the first place by trying to get the job done as cheaply as possible. Not only did they end up hemmoraging cash trying to fix the mess they had, they were losing business with their god-awful website.

“Quality” is often not cheap.

Unfortunately, not everyone knows enough to call “bullshit” on a proposal that costs a lot less, but doesn’t have the legs to meet your needs. In the case of the client mentioned here, the person in charge was NOT technical (they were actually in marketing).

I know of several instances in which companies have gotten burned by deciding to do things as cheaply as possible. This client simply did a more spectacular job of it than some of the others.

Let’s face it, it takes a certain amount of work to do things right. Most people don’t skip getting a foundation built for their house, skimping on a critical resource like your e-commerce infrastructure makes even less sense.

-Daniel