Towards an understanding of technical debt

What I described isn't perfect; it's impossible. It destroys the utility of the idea of technical debt if that's the baseline, because it means that all choices are between "really bad" and "really bad".

"Aside, the first and last lines of your comment reminded of this post:"

Oh, certainly. But people do tend to assume that all comments that are not completely complimentary are intrinsically disagreement, and, well, let's be honest... statistically, it's true, so it's hard to be too annoyed that people's brains make that inference by default.

I think the SE Radio episode on Technical Debt http://www.se-radio.net/2015/04/episode-224-sven-johann-and-...

Does a good job of explaining why technical debt occurs, how to avoid it and when technical debt is ok.

I strongly recommend everyone listen to this episode. It's quite insightful.

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() { ... }

    void
    f()
    {
       ...
    }

    /*
    
    */
    void
    f()
    {
       ...
    }

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.

To understand why, let's consider a normal interaction with a corporate legal team. The content team submits some copy to the legal team for approval and the legal team needs to communicate to the content team that they can't make the claim they are trying to make about the product. Now, it's more true in the technical sense for legal to say things like "Section 3 paragraph 7 of the Fair Sales Act states that Consumer Entities as defined in Section 1 Paragraph 3 may not represent their products in such a way as to potentially mislead a Purchaser as defined in Section 2 paragaph 9. Furthermore this issue has been thoroughly litigated at both the federal appellate and Supreme Court levels which have reinforced those interpretations unfavorable to the aforementioned Consumer Entity." But that wouldn't be great for either department. It's more useful for Legal to just say "You can't claim that - we'll get sued." In a similar way, it's more useful as a software engineer to just say "that decision will add to our technical debt" than to try and discuss the minutiae of how a certain bad architecture decision will make the system "resistant to change". As a fellow engineer, I'd rather have the latter conversation with you and the one about "technical debt" with my business manager.