CC: Technical Credit

[bartlettroscoe]

Some people are trying to define software development "Technical Credit" as opposed to "Technical Debt" as a primary software engineering metaphor. Some example articles include:

• "Technical Credit", 2024: https://dl.acm.org/doi/10.1145/3690043 (Ian Gorton, Alessio Bucaioni, Patrizio Pelliccione)
• "Technical Credit", 2024: https://cacm.acm.org/opinion/technical-credit/ (Ian Gorton, Alessio Bucaioni, and Patrizio Pelliccione) [Same article as above]
• "Technical Credit. The Other Side of the Technical Debt Coin", 2023: https://medium.com/@berniebrussel/technical-credit-the-other-side-of-the-technical-debt-coin-434d0514dfc7 (Ian G)
• "Technical Credit", 2016: https://www.stillbreathing.co.uk/2016/10/13/technical-credit (chris)
• "On Technical Credit", 2014: https://www.sciencedirect.com/science/article/pii/S1877050914001252 (Brian Berenbach)

It seems there are other articles found in this Google Scholar search that mention "Technical Credit" going as far back as 2012. But there are not many.

The most recent 2024 article defines Technical Credit as:

What Is Technical Credit?

Essentially, TC characterizes system features that can yield long-term benefits as the system evolves. By highlighting the benefits of strategic investment, TC contrasts with the conventional TD-driven focus on the drawbacks of sub-optimal choices. Rather, TC advocates for a paradigm shift toward recognizing the positive potential of forward-thinking decisions. We believe that framing TC as a counterbalance to the dominant technical debt-centric view can unlock a more nuanced, rounded understanding of a system’s attributes, qualities, and its intrinsic value and investment.

The 2014 article "On Technical Credit" defines it as:

Technical Credit is the investment in the engineering, designing and constructing of software or systems over and
above the minimum necessary effort, in anticipation of emergent properties paying dividends at a later date.

I am not sure the that "credit" is the best metaphor for this concept. In financial terms, "credit" is just the permission to take on debt. A better metaphor for what they are trying to describe is more like "Technical Reserve" or "Technical Capital Reserve". But I would have to read all of these articles to make a fair evaluation of this. At face value, doing this type of speculative over-engineering would seem to be anti-agile. This is much more akin to "Big Upfront Design". (I will note that "agile" does not seem to be mentioned even once in any of the above articles.)

The most recent ACM article proposed as research agenda for "Technical Credit". Is it worth it?

[bartlettroscoe]

Is this worth as BSSw CC article? It feels like getting into the weeds compared to the more important concept of Technical Debt (which is always an issue).

[markcmiller86]

In financial terms, "credit" is just the permission to take on debt.

Hmm...I can see that when we are talking about extending credit to someone or something. But, when thinking in terms of a balance sheet, the term "credit" then refers to a positive balance whereas "debt" refers to a negative balance.

That being said, the original concept of "technical debt" (as I understand it anyways) I think arises out of the idea of knowingly doing something less than properly (not all the way, not everything that should have been done, not really the right way, something you know you are going to have go to back and put more effort into again later to bring up to par) in the interest of expedience. That is, you are knowingly kinda sorta borrowing something from the project now that you know you will have to pay later. You are effectively taking on a debt.

Extending the "technical debt" metaphor with the concept of "credit" IMHO then means identifying who or what is the "creditor". To who or what is something owed? To who or what are you indebted? IMHO, the concept of a credit or of creditors relates to the various others who are stakeholders in the project (maybe other developers, certainly sponsors and customers/users who may have to adjust priorities, accept delays or pay more in the future).

Like you, @bartlettroscoe, it feels like the first article you cite, is using the concept of "credit" (as an extension of the technical debt metaphor) incorrectly (or at the very least, not in the intended contrast with "debt" as it is used in "technical debt"). That is because the TD metaphor is based on knowing the one proper (right, true, correct) way to implement something which all other implementations are measured against. The debt is against that one, true implementation. That one, true implementation is the way it should be done. That is the debt free case (e.g. 0 balance).

To really wrap our heads around the concept of technical credit proposed in that first article, one would have to have a conceptual model of implementations which starts from a "sufficient" (good enough, practical) implementation (that one implementation which properly balances all concerns both long and short term, both technical and non-technical, etc). Then, TD implementations are less than the sufficient one and TC implementations are more than the sufficient one.

[bartlettroscoe]

In financial terms, "credit" is just the permission to take on debt.

Hmm...I can see that when we are talking about extending credit to someone or something. But, when thinking in terms of a balance sheet, the term "credit" then refers to a positive balance whereas "debt" refers to a negative balance.

Okay, I can see that in the context of a balance sheet. But they don't make that analogy clear. (But if they did, it would help.) When to talk about debt and interest payments, "credit" means something different. Confusing.

That being said, the original concept of "technical debt" (as I understand it anyways) I think arises out of the idea of knowingly doing something less than properly (not all the way, not everything that should have been done, not really the right way, something you know you are going to have go to back and put more effort into again later to bring up to par) in the interest of expedience. That is, you are knowingly kinda sorta borrowing something from the project now that you know you will have to pay later. You are effectively taking on a debt.

Tech debt can be accumulated knowingly and unknowingly (see). Likewise, people can get into financial debt without even realizing it (e.g. if they don't understand what they are doing). So taking on known and unknown tech debt is a good analogy.

To really wrap our heads around the concept of technical credit proposed in that first article, one would have to have a conceptual model of implementations which starts from a "sufficient" (good enough, practical) implementation (that one implementation which properly balances all concerns both long and short term, both technical and non-technical, etc). Then, TD implementations are less than the sufficient one and TC implementations are more than the sufficient one.

Right, but deciding to put in extra effort upfront to try to build up "Technical Credit" means that you are fairly sure what will happen in the future so you will see a payoff. More often, I have seen people try this (including myself) and over-engineered a given part of a system that ended up being Technical Debt because they had a poor prediction of the future.

However, one area were I might see where some more up-front work that would likely pay off in the future (and therefore may be classified as "Technical Credit") is in investing in build systems, test systems, automated testing, static analysis, dynamic analysis, enforcement of coding conventions, etc. Often, projects don't do this at the beginning an it leads to a lot of tech debt.

Otherwise, Technical Credit might just be an attempt to rebrand "Big design up front (BDUF)" by a new name.

But there are people I respect that believe in BDUF for many situations, e.g.:

• https://www.joelonsoftware.com/2005/08/17/the-project-aardvark-spec/

So perhaps that point of view deserves a modern take in the context of the tech debt discussion?

[markcmiller86]

Otherwise, Technical Credit might just be an attempt to rebrand "Big design up front (BDUF)" by a new name.

I do worry a lot of communities, including our own, has a bias towards rewarding these kind of rebranding activities.

[markcmiller86]

@bartlettroscoe what is your sense of how much this concept of "the standard against which all implementations are measured" being either the perfect/ideal or the sufficient/good-enough is already handled in the literature? In the former, there is no room for credit because all implementations are less than the ideal/perfect (e.g. TD implementations). In the latter, the standard for what is idea/perfect is the one achieving the best balance of all things considered (e.g. minimze total cost over the life of the project). Some implementations will be "better" (TC) in that they put in place functionality that can potentially be used to reduce costs for some later, perhaps unknown (or maybe just unplanned) requirements and some will be "worse" (TD) in that they fail to meet all known/expected needs.

Its probably just my own lack of experience with this topic but I am now wondering if there is room in the literature somewhere to introduce and describe these concepts as I don't think the articles above (I've read two now) actually do.

[bartlettroscoe]

@bartlettroscoe what is your sense of how much this concept of "the standard against which all implementations are measured" being either the perfect/ideal or the sufficient/good-enough is already handled in the literature?

I don't think anyone can honestly define the perfect/ideal software design, implementation, etc. There is better and there is worse (by some metrics). Every software architecture, design, implementation, etc. is a set of compromises and trade-offs. So what is you global objective function that you are using the define "perfect/ideal"?

In the former, there is no room for credit because all implementations are less than the ideal/perfect (e.g. TD implementations).

Right, but I think the idea is that even if the current architecture/design/implementation is "perfect/ideal" for the current set of functionality, it may not be the best once you add more requirements and features. The idea with Agile Emergent design is that the current implementation is the best it can be for the current set of features, but you expect that design to need to change once you add more features. I think the idea is that with BDUF, you can create an architecture/design/implementation that works well now but will also make it cheaper to add new features in the future and require less rework/refactoring. But good agile design already does that to some extent (there are good discussions of this in Bob Martin's book Agile Software Development).

In the latter, the standard for what is idea/perfect is the one achieving the best balance of all things considered (e.g. minimize total cost over the life of the project).

That is the holy grail of BDUF; Often attempted, but seldom achieved.

Some implementations will be "better" (TC) in that they put in place functionality that can potentially be used to reduce costs for some later, perhaps unknown (or maybe just unplanned) requirements and some will be "worse" (TD) in that they fail to meet all known/expected needs.

There is a fine-line between applying good software development practices and design up front to avoid the needless accumulation of TD (see "Much of the otherwise reckless and/or inadvertent technical debt can and should be avoided in the first place by applying well-known software development best practices.") vs going above and beyond to try to anticipate the future. "Difficult to see. Aways in motion is the future", Yoda.

Its probably just my own lack of experience with this topic but I am now wondering if there is room in the literature somewhere to introduce and describe these concepts as I don't think the articles above (I've read two now) actually do.

Perhaps. But it may be worth a good CC article.