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

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

0 reposts0 likes

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

to be clear, this is what I'm referring to bsky.app/profile/kyle... your guesses are rarely going to be correct by the time you need the thing, requirements will have changed, and now you're building on a crooked foundation yagni until you do

Kyle@kylestratis.com

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

You're agreeing with what I said though. Tech debt often comes on in the interest of speed or *current* simplicity even though it may not be the right choice for the future. Tech debt is cheaper to take on now, because the cost to fixing that foundation when you actually need to has plummeted.