Editorial Note: I originally wrote this post for the NDepend blog. Go check it out over there, if you’re so inclined. You’ll like the posts over there if you like static analysis and philosophical discussions of software design and architecture. Also, this week will probably consist mainly of cross posts as my wife and I are going to spend a few days in a hotel in New Orleans, taking in the spectacle of Mardi Gras.
One of the things I remember most vividly from my CIO days was the RFP process for handling spikes in demands on my group’s time. In case you haven’t participated in this on either side, the dance involves writing up a brief project description, sending it over to a handful of software consulting firms, and getting back tentative project proposals. I’d pick one, and work would begin.
There were a lot more documents and legalese involved, but the gist, writ small, might be something like, “we need an application that will run in our data center, take information about customers out of our proprietary database, and put it back into our CRM as notes, depending on a series of business rules.” The response, in proposal form, would essentially be, “we’ll do that, and we think it’ll cost you about $30,000.”
This is what most people think of as the cost of a software project. Perhaps it’s not a little, 5-figure line of business utility. Perhaps it’s a $300,000 web or mobile application. Perhaps it’s even a $30,000,000 enterprise workflow overhaul. Whatever the case may be, there’s a tendency to think of software in terms of the cost of the labor necessary to write it. The consulting firms would always base their proposals and estimates on a “blended rate” of the hourly cost of the labor. Firms with in-house development staffs tend to reason about the cost of software projects as a function of the salaries of the folks tasked with the work.
Of course, if you’re a veteran at managing software projects and teams, you realize that there’s more to the total spend than just the cost of the labor. No doubt you factor in the up-front and licensing cost of the tools you use to develop the software as well as the cost of the hardware on which it will eventually run. You probably even factor in the cost of training users and operations folks, and paying maintenance programmers to keep the lights on.
But there are other, more subtle costs that I’d like to discuss — costs related to your approach to software development. These are variable costs that depend on the nature of the code that your team is writing.
To really get at the total cost of software ownership requires an understanding of the concept of technical debt. To communicate this concept, I’ll use an analogy rather than talking about software. Imagine that you’ve cooked dinner, and you’ve used a whole lot of different dishes and utensils, all of which are now piled haphazardly in the sink. They’re dirty and covered with drying food debris that, left untended, will make them very hard to clean.