Using Metrics to Find Out if Your Code Base Will Stand the Test of Time

So your software development team finally finished the project. A celebration has ensued, and you are now the happy owner of a new technology solution. Congratulations! But are you really finished? What will maintenance of that code base cost you over the next few years? In this article, technology consultant Aaron Erickson, author of The Nomadic Developer, covers metrics you can use to determine whether your code base will stand the test of time—or be a significant source of ongoing cost.

From the author of

Cost of ownership. Perhaps we should think about that term for a bit. Why did we start using it? Maybe I am on an island here, but I thought technology was supposed to reduce cost and increase revenue. So why are we so obsessed about cost of ownership?

The realitysad as it isis that we are either really bad at selling how valuable technology solutions are, or we build maintenance nightmares that cost so much money that any benefit we might derive from them is overwhelmed by the costs we incur to maintain the solutions. After nearly 20 years of seeing the state of hundreds of production systems in such disarray, I suspect it is the latter. The time is nigh to do something about it.

One place to look is in the innards of how most systems work. By that, I mean those evil three words, namely, "the source code." Everyone sings praises about good design. We all know we should do it. Our best practitioners know the SOLID principles that help us write better code. Sadly, despite that these concepts are not that difficult, the same kinds of problems persist, even in code written today! The time has come to stop accepting this state of affairs and start measuring just how bad our code is.

The point of this article is to not only preach the gospel of "thou shall not write bad code" but to give you a means of measuring just how bad your code base is, and solutions for dealing with the problem.

Why Metrics Matter

The highest value scenariosinternal corporate applications that do things that such as complex processing, statistical oriented business intelligence, or other already complex domainshave no room for artificial complexity. The inherent complexity is enough. Complexity around how you connect to databases, XML files, Excel files, or other various utility functions is simply not affordable in a world where technology solutions have to prove value in months, not years.