Using Metrics to Find Out if Your Code Base Will Stand the Test of Time
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 realitysad as it isis 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 scenariosinternal corporate applications that do things that such as complex processing, statistical oriented business intelligence, or other already complex domainshave 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.