[rubidium]

There's a lot of ways to parse technical debt. The simplest one I've found, while it has its shortcomings, is this from a Deloitte article:

They state, in general, it costs $3.61 technical debt / line of code.

"Technical debt is a way to understand the cost of code quality and the impacts of architectural issues. For IT to help drive business innovation, managing technical debt is a necessity. Legacy systems can constrain growth because they may not scale; because they may not be extensible into new scenarios like mobile or analytics; or because underlying performance and reliability issues may put the business at risk." (Tech Trends 2014, Deloitte University Press).

It's an easy to use metric to weigh the cost of supporting programs, and relatively simple for managers to understand. It has the added benefit of encouraging reducing the size of the code-base when possible.

[makecheck]

Well the problem with that analysis is, what qualifies as a "line" of code?

An efficient algorithm may be punished over an inefficient one. An optimal one-liner can certainly cost a lot to develop (maybe you need a smart engineer, a lot of testing and a lot of time to figure it out) yet it would appear to be cheap.

Then there's just textual differences. It depends on the programming language. And it can be different even in the same language...

This function has one line:

    void f() { ... }

This function has 5 lines:

    void
    f()
    {
       ...
    }

This function has many lines:

    /*
    <several lines of comments>
    */
    void
    f()
    {
       ...
    }

[mcherm]

You are pointing out that "lines of code" is a terribly imprecise metric. That is TRUE, but not HELPFUL. We all know that "lines of code" is a terrible metric. And for only $100/hr, for a few hours you can hire an expert to evaluate one file from your codebase and determine its size in something more reliable -- "function points" or some other system that you devise.

The thing about "lines of code" is that it's CHEAP and EASY. It is also WAY better than having nothing. Which system is more complex, system A written in C++ 2003 or system B which was written Java in 2013? Which system is more complex, System C which is 200,000 lines or system D which is 10,000 lines? Even if I don't tell you how "lines" were defined in those two estimates, you can still tell more about C and D than about A and B.

"Lines of code" is a terrible metric, which can give only order of magnitude estimates. But that makes it enormously better than no metric at all, or a complex metric which we haven't actually measured.

[makecheck]

The idea is to encourage the best behavior. A bad measurement encourages developers to focus on the measurement instead of the real problem, and in this respect it is worse than nothing at all.

A shorter function is a great side effect but it should never be the point. I want someone who can do things like: find obsolete code, create a better algorithm, decides on a better language for the task. If I say that a system is bad because it's 200,000 lines, I may discover that developers are really good at removing comments and obfuscating code to "improve" it down to 150,000 lines. If I come up with specific performance improvements, and state clear expectations such as "find functions we never use", I end up with a more maintainable system.

[mcherm]

Of course!

Let me be clear: I will defend "lines of code" as a metric useful for getting and order-of-magnitude estimate of the complexity of any given codebase. Anyone using it as a metric to determine how much to reward developers is just plain stupid.

[1] - http://www.folklore.org/StoryView.py?story=Negative_2000_Lin...

[2] - http://dilbert.com/strip/1995-11-13

[rubidium]

You missed the point I think.

Ideally, you want minimal technical debt. Any code you develop should aim for minimizing technical debt. Technical debt is not about evaluating the value of a line of code or program, but about it's potential maintenance cost.

I work at a large organization that maintains over 300+ modules of code and custom software programs, varying in size from a thousand lines of code to massive ones. Any one of which can be sold at any time, and all of which is supported in some fashion or another, and all of which should be able to work together.

You need some sort of metric to see where to invest ones time. If you don't manage the technical debt, everyone spends all their time doing tech support.

So, how the helpful concept of technical debt is evaluating where to put effort into improving the code base, and evaluating potential support cost of adding more modules? Lines of code, while flawed, provides a pretty good starting point.

[makecheck]

As I mentioned in another comment, you don't want developers focusing on lines of code. The directions have to be much clearer, such as the goals of finding unused code or improving performance.

If resources are handed out based on how bloated a project is, you would quickly discover how creative developers can be in increasing the relative "importance" of their code.

Systems are composed of lots of things, and sometimes a tiny piece is the most complex and critical. A measure of lines of code should not prevent you from adding 3 more people to a tiny project, and removing a person from a team with a giant code base.