The Psychology of Technical Debt

The Muscle Memory You Build Is the Muscle Memory You Keep

When a team writes code, they are not just producing a working feature. They are also building muscle memory about how the work gets done. The shortcuts they take become habits. The habits become the way the team works. The way the team works becomes the codebase.

If a team takes a shortcut on accessibility on the first feature, the second feature will skip accessibility too. Not because the second feature decided to. Because the muscle memory is now to skip it. The team is not making the choice fresh each time. The team is repeating what the team did last time.

I learned how strong this is from the other side of it. I was preparing a coding example for an accessibility class I was teaching. The example was supposed to be inaccessible, so the students could see what bad code looks like and how to fix it. I coded the example, ran the accessibility test, and it passed. The test was supposed to fail. I had to look at my own code to figure out what went wrong. The answer was that I had not been writing an inaccessible example. I had been writing my normal code. My fingers and my brain had gone automatically to the accessible version because that is what years of practice had wired in.

The lesson cuts both ways. The team that practices accessibility will eventually do it without thinking. The team that practices skipping it will eventually skip it without thinking. The leader picks which one the team practices.

Why "We Will Fix It Later" Is Rarely True

The phrase that creates most technical debt is "we will fix it later." It sounds reasonable in the moment. The deadline is real. The shortcut works. The team will come back to it.

The team almost never comes back to it. Not because the team is lazy or unprofessional. Because by the time later arrives, the team has new work, the shortcut has been built on top of, and the cost of fixing it is now higher than it would have been to do it right the first time. The leader who said "we will fix it later" was making a promise on behalf of a future team that does not exist yet.

The honest version of "we will fix it later" is "we are not going to fix this." Once a leader can say that out loud, the conversation about whether to take the shortcut becomes a different conversation. Some shortcuts are worth taking when the real cost is named. Most are not.

Accessibility as a Special Case of Technical Debt

Accessibility is technical debt that happens to also be a legal risk and a customer experience problem. The pattern is the same as any other debt. The team takes a shortcut on the first screen. The shortcut becomes the pattern. The pattern propagates across the product. By the time somebody notices, the cost of fixing it is no longer "rewrite this screen." The cost is "rewrite the product."

I have watched companies discover their accessibility debt at the worst possible moment. After a customer complaint that turned into a legal letter. During a procurement cycle where a buyer asked for a VPAT. During a leadership transition where the new leader asked a basic question that the old leader had been avoiding. None of those are good times to discover the debt. All of them are common.

The companies that get ahead of accessibility debt do one thing differently. They treat it as a normal part of the work, not as a special project. The debt does not get a separate budget. The prevention gets built into how the work gets done.

Prevention Is Cheaper Than Remediation, and Almost Nobody Acts Like It

The numbers on this are not subtle. Catching an issue during design costs a fraction of catching it in development, which costs a fraction of catching it after release, which costs a fraction of catching it after a customer or regulator finds it. Every team I have ever talked to knows these numbers.

Almost no team acts on them.

The reason is not ignorance. The reason is that prevention costs feel like adding work, and remediation costs feel like normal work. The team that pays for prevention sees the cost on every sprint. The team that pays for remediation sees the cost in big chunks that look like accidents. Big chunks that look like accidents do not feel like the team's fault. Steady costs on every sprint do.

The leader's job is to make the steady cost the visible one. Once the team can see that prevention is cheaper than remediation in their own data, the conversation about which one to fund becomes easier.

How to Change the Team's Relationship With Debt

There are a few moves that work. None of them are technical.

Technical debt is a habit, not a balance sheet. The team's muscle memory about how the work gets done is what determines whether debt accumulates or gets paid down. Prevention is almost always cheaper than remediation, but only if the leader makes the steady cost of prevention more visible than the chunky cost of remediation. Name the debt. Build prevention into the definition of done. Stop promising future teams they will fix what current teams skipped. The team you have today is the team that will pay the bill.