The UX of Technical Debt

Technical Debt is a fairly common metaphor used in software development.  (Nice write up.) Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise

I believe that User Experience design has a similar debt metaphor happening.

Everyone wants to have a great product.  However, according to Predictably Irrational by Dan Ariely, people will defer things they need whenever possible.  In other words, if you ask someone if they want a healthy meal or fatty one for next week, they will choose the healthier option.  If you ask them today, they will choose the fatty one.

When you ask a manager if they should pay down technical debt one day, the answer is yes.  If you ask them if you could pay it down NOW, the answer is no.  Few managers wants to stop building features to rewrite code they already wrote.  One manager I met said, “Why didn’t they just write it correctly the first time?”

The answer is simple:  Managerial pressure for deadlines.  This is a universal truth.  All managers want to have their feature or product sooner than is possible to do without building up technical debt.  People just cut corners to squeeze the project into a shorter time span.

The killer thing about technical debt is the interest payments.  As a company keeps growing and keeps cutting corners, the technical debt compounds and creates a situation where most of your time is spent dealing with the low quality and less and less time is spent building new features.

In terms of User Experience, the same metaphor holds true.  If you don’t build in the features that create a great experience when you first launch the feature/product, the reality is that you will not be able to go back and improve it later.  It is the little things that make a product wonderful.  Not putting them in early means that you won’t have the success that comes from great UX.  This means there is more pressure to fill the void with features.  It’s a death spiral.  Just like technical debt, the UX debt can become overwhelming until you literally must redo the entire UI layer.  Ask management for that and you know the answer you will get.

The lesson is simple: There is never time to do it right, but doing it wrong will lead to failure; personally and professionally.  This may be the number one cause of poor products.  Find a way to do things right and not accumulate technical debt or you will find yourself under a mountain of interest that you will not be able to pay off.

One response to “The UX of Technical Debt”

Whatya think?

%d bloggers like this: