Post

The cost of introducing and paying off tech debt has changed very, very much and I don't even know most of us have the time and space to think about what it means Tech debt has been so central to the software craft for decades, and now... how much does it matter?

because people will suddenly start reading the code again in 12-18 months? seems unlikely those who are still reading the code already know, and the rest don't care 🤷‍♂️

You can incur tech debt while reading the code, the two things are unrelated. All this means is you can experiment faster and take on tech debt in service of some goal because it’s easier (read: cheaper) to fix in the future.

no one said you can't incur tech debt while reading the code claiming the two are "unrelated" is (excuse be but) preposterous

0 reposts0 likes

Sure they are. Incurring tech debt happens whether or not you read the code, when it’s done consciously, the decision is made outside of reading the code entirely. Even detecting most classes of it doesn’t require reading the code, observability, complexity checking, etc. have existed for years

debt happens whether or not you read the code, I never claimed it doesn't I claim it happens *less* when you read the code, more when you don't again, if you haven't read the code, you don't know what you don't know, which means you can't even ask debt happens either way - but at different rates

And I don't think that's the case. Tech debt is (IME) typically incurred consciously, the cruft-buildup form of tech debt is a process issue and doesn't require reading code to avoid or mitigate. Tech debt (and non-TD issues like inappropriate or disjoint architecture choices) are well-known

enough that you often don't need to read the code to ask an agent to find any and report to you. I think knowing the codebase *helps* but again IME reading code is such a weak preventative I feel ok saying it's unrelated to incurring tech debt.

claiming it's easier to fix in the future is also fairly moot, because you can't fix it if you don't know it's there, and you won't find (all of) it unless you read the code if your agent could find it, it wouldn't exist in the first place alas 😌

IME tech debt is usually taken on consciously, and agents properly applied tend to be able to spot it more reliably than humans. Whether you take on tech debt or not has changed with agents, because often they can do it “right” to begin with, but a) not always and b) taking on TD is still useful at

times, like reduced upfront complexity (in code or infrastructure) to avoid premature optimization that will eventually need to be addressed with eg user growth.

disagree. things grow and change over time decisions that were correct become suboptimal over time there was often no way to know at the time that something was going to become debt any code that sits untouched on a shelf eventually grows bugs or turns into debt "time makes fools of us all"

This has never been a major source of tech debt IME, and is often easy to catch with tools we've had for years (which is partially why it hasn't been a bigger source than, say, management).

it's nobody's fault either developers who think they can predict the future usually end up creating even more debt, by building the wrong things, facilities that never actually get used, frameworks we didn't need, premature abstractions that never pay off can't be fixed, just the nature of reality