Hacker News Reader

Comment by coding123 | Hacker News Reader

I think of all the code written as technical debt. As soon as you write it, it becomes a burden - just like regular financial debt. However instead of thinking of code like a credit card loan that will take a few years to pay off, think of it like a mortgage that you have for 30 years. At the 30 year mark, you will generally have retired the code, hopefully. If you're not so lucky, you should expect to see balloon payments coming shortly. I know this isn't a perfect metaphor because honestly "technical debt" applies to all code, not just slightly bad code. That's very different from a loan.

View on HN

I suggest that all code is a liability, rather than a debt per se.

This assumes all things can be usefully viewed through the prism and language of economics (though my gut feel is few things can or should be).

The accounting world considers code an asset and allows you to amortize its creation.

Making progress in the world is fighting against entropy. Just because it is hard to fight the disorganizing efforts of the universe doesn’t mean that your output is a liability.

Liabilities are debts.

> liability: a thing for which someone is responsible, especially a debt or financial obligation.

According to the balance sheet equation,

> Assets = Liabilities + Owners Equity

Certainly all code is a liability - it must be at least understood and maintained from time to time (80% of lifetime cost is in the maintenance).

And while an accountant might also mark it an asset - not all code is an asset - and we recognize that fact when we delete for badness or disuse - or rewrite it to make extending and maintaining it easier.

As intimated, I'm not sure that the fuzzy language and world of economics is the best way to view such things, however ...

I'd accept that debts are a subset of liabilities, but not that 'liabilities are debts'.

A debt implies an externality, while a liability implies some generic exposure -- it's that which I focus on when considering (all) code as a risk to an organisation.

I suspect, however, that we agree on the fundamentals. There's some cost and risk to developing and trying to maintain any code base, and accepting that can usefully inform development and operations work better than thinking of code as a (near-)risk-free asset.

Code is a liability it can be hacked if not written securely. It can be out of date if the language changes or Windows changes and the company upgrades, which means parts of it need to be rewritten.

I used to program COBOL on IBM 370 DOS/VSE systems they later went to Visual BASIC on Window 3.1 PCs. The conversion took a long time and most code had to be rewritten because COBOL is not BASIC. Management didn't care about that, they just wanted a working project. We all did our best going overtime without pay and working weekends to meet deadlines.

COBOL was a liability when they wanted to convert to Visual BASIC. There was liability to convert the code, convert from DB2 to SQL Server on the database end.

Overtime without pay is financial debt.

That's not debt. That's an asset. It's inventory. It has a maintenance cost in the sense that a truck has a cost of upkeep to keep it on the road.

Technical debt is configuration and plugins. You are able to deliver something now with the benefit of changing behaviour later but at the cost of having an enormously increased test surface and invasion into your type system with possibly hostile parameters.

I would say debt == investment.

You're betting that the maintenance foregone in the present is paid back with interest in the future.

This "pay back" could be the success of the company which allows you to pay for more developers and tools.

Is it worth it? Time will tell.

Without the code the company is nothing, so it's definitely not 'debt'.

If that were the case, the company would have a negative value.

Code is asset that requires maintenance.

But yes, it's definitely worth reminding ourselves of the ongoing cost of maintaining code.

> Without the code the company is nothing, so it's definitely not 'debt'.

I reconcile the concept that code is a debt with your statement in the following way:

The feature produced by a piece of code can be an asset, but the code itself is a debt.

Thus, for a new feature to be valuable, you want the value added of the feature (or asset) to out-weight the cost of the code (or debt).

As a general rule, the complexity that comes along with a piece of code grows as the code-base and feature set grows, thus, for a young codebase, the value of a feature more easily out-weights the cost of the code.

Anything in any other business terms that needed to be used, created or maintained to create value for customers would not be debt.

'Technical debt' is just not debt, it's just an interesting way to think about it, and a neat use of lingo.

There are any number of other business practices for which one could try to apply the same analogy, but it wouldn't work because very quickly the term wouldn't seem right.

For example 'training employees' for a situation, knowing they might need to be trained differently in the future, is not going to be regarded as debt.

Same thing for processes, investment in equipment, parts, materials etc..

It's a metaphor not actual money that can create a negative value.

Although, you could say that a lot of profitable companies have negative value codebases where the cost to rebuild them is less than the cost to maintain.

This probably explains why some companies get replaced by small nimble startups.

Reply on news.ycombinator.com