Total Cost of Ownership - a Story

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/total_cost_of_ownership__a_story.htm]

A company needs some software service that isn't their standard-line of business, so they outsource it to you (and your company) and pay for the application. So far, so good.

But then, as the client is using your app, they're struggling on the employee search filter page. After getting frustrated for five minutes, they ask their coworker if they know how to work it, just to make sure it's not some obvious mistake. After neither one can figure it out, they think it's an error (not the friendly name "bug", but an error, and to them a critical and fatal one).

So, they phone your company's customer service rep, who rushes around trying to find a fix, and inevitably has to get back to them. After a string of High-Priority emails between the customer service rep and several maintenance developers and documentation writers, the customer service rep is confident that this is an "issue" (perhaps an "error", but issue sounds less blamable), they apologize to the client and offer that it will be fixed in the next release - several months in the future. "No deal" the client says, "We need this now."

Your company's account manager (who oversees that account) gets involved, trying to work their magic diplomacy to make everyone happy. But the client insists "we need this - the thing simply will not work for our business cases without it." So, your company being one that always puts the customer first, pulls in an executive who directs the issue to a developer who can make a fix right away, and hopefully get out a patch or hotfix.

The developer drops whatever they were doing, losing all the momentum they have built up for their current task, and re-mobilizes to hunt down this issue (which is in code they never even wrote). They coordinate with a product manager to make sure they understand the exact new functionality. After spending hours coming up to speed, and ensuring they can reduplicate the bug, the developer finds a fix. It was one line that needed to be updated. Indeed, it often seems that these types of bugs are "just" one line.

The code is sent as an emergency item to QA, who redeploys their environment, confirms the fix, does a little regression to make sure it didn't break anything else. After all this, they then sends it to IT, who stays late that night to make a special patch deployment.

The team's work pays off - thanks to hours and hours from the customer service rep, the account manager, the product manager, the developer, the QA tester, and IT - one line of code has been fixed in production, and the client is happy again. For some development shops, this is actually optimistic, as many places wouldn’t just dismiss it as "a small issue" or have to wait to the next release instead of patching right away.

However, while it's great that the team was flexible enough to handle this change, think of the cost. Here's the problem. Fixing that one-line bug after production release could have easily cost hundreds of times more resources than just doing it right the first time. If it took the whole team 16 people-hours, and the original developer could have caught it with an extra 5 minutes of unit testing, then this was a colossal waste of time. The problem is that many developers insist (and managers cave in to) that "I just don't have time" to do . And then from their short-sighted perspective, they've saved the company time because they got the feature done 5 minutes earlier. However, the total cost of ownership - not just the developer creating the initial feature, but everything else involved (like QA and maintenance) is what really matters. If a sloppy developer can shortcut 5 minutes, only to waste the team hours later - whose really coming out ahead? Answer: Your competition.