Towards an understanding of technical debt • Hacker News Board

Re: Towards an understanding of technical debt

#21

Post by makecheck » Wed, Jan 13, 2016, 5:25 PM UTC

mcherm wrote: post #17

makecheck wrote: post #15

Earlier quoted context omitted.

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…

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…

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.

Re: Towards an understanding of technical debt

#22

Post by makecheck » Wed, Jan 13, 2016, 5:35 PM UTC

rubidium wrote: post #18

makecheck wrote: post #15

Earlier quoted context omitted.

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…

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…

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.

Re: Towards an understanding of technical debt

#23

Post by paulddraper » Wed, Jan 13, 2016, 5:55 PM UTC

NumberSix wrote: post #16

Technical debt is a very artificial concept. With real financial debt one knows immediately the exact dollar amount, the interest rate, the payment terms and so forth. There is usually no ambiguity or judgment. In contrast, technical debt is based on theories about software development and uncertain predictions about future changes to the software. As the old saying goes: "prediction is hard, especially about the fut…

The fact that future payments are unknown doesn't make them artificial.

Avoiding effort now causes more effort to be spent later. The amounts are unknown but the effort is real.

Re: Towards an understanding of technical debt

#24

Post by brazzledazzle » Wed, Jan 13, 2016, 7:23 PM UTC

Obviously this is about development but that's not the only place where you can accrue technical debt. In operations it's shortcuts or bandaids so you can get something done quickly or fix a production issue "ASAP". While it is a trade off it's a crippling one. Without good engineering principals and management support to regularly pay it down you can easily get to a point where the collective fragility has you putting out fires constantly and no one wants to touch anything.

Unfortunately management often thinks that they're supportive but ask them what project they need to axe or put on the back burner to free up time and the ephemeral promises and deferment to some hazy future date get put on the table.

Perhaps it's not "real" in development but it is very much a real issue that needs to be thought about by anyone in charge of operations.

Re: Towards an understanding of technical debt

#25

Post by _asummers » Wed, Jan 13, 2016, 11:38 PM UTC

makecheck wrote: post #14

I combat this by ensuring that it is perfectly acceptable for a change to consist primarily of deletions . You don't want a culture that only adds features, forever growing the pile. Developers need to be free to identify and aggressively throw out old functions, old tests, obsolete documentation or anything else. This means that a list of deprecated items should be expected in most projects, and mean it when you war…

At my current job, I've removed 20kloc more than I've written in a 200kloc ish code base. Deleting code is one of the most enjoyable experiences of the development process in my mind.

Re: Towards an understanding of technical debt

#26

Post by mcherm » Thu, Jan 14, 2016, 1:18 PM UTC

makecheck wrote: post #21

mcherm wrote: post #17

Earlier quoted context omitted.

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…

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 syst…

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