Sometimes it feels like junior engineers and product folk don’t quite get what technical debt is.  Actually, they understand what the term literally means but not the impact.  Here is a little fun analogy to help.

Imagine you live with your spouse in a nice tidy apartment.  You receive a call about a job interview for a position that is double your current pay but you have to interview right away.  So you turn your closet inside out looking for your best interview outfit.  Shoes, clothes, etc.. strewn around your apartment.  You’re dressed to your best but your apartment is now a mess.  Since you are in a rush, you leave everything and head to the interview.  While you are at the interview, your spouse comes home and trips on a pair of shoes you left out spraining his or her ankle.

The best case scenario is you get the job, but now you have to take care of your spouse and clean up the apartment.  It’s more likely that you didn’t get the job, your spouse is livid, you and your spouse need to clean up the apartment, and you now have to take care of your spouse.

Technical debt is the mess you leave to hopefully make some extra money off of a product feature.  The mess you make is in code and not in your apartment.  It can lead to bugs and outages.  Messy code and systems can be hard to maintain and build off of.  Each subsequent product feature becomes harder to build.  Engineers get angry dealing with a mess so they leave.  The next set of engineers cannot navigate the mess so they are constantly angry.

The thing is, if you had texted your spouse to leave a warning about the mess and cleaned up right when you got home from the interview, everything would have been okay.  It’s the same with technical debt, sometimes you need to make a mess but if you actually plan for it and clean it up, you will be okay.

Try to avoid technical debt.  But we all live in the real world so if it is necessary, pay it down quickly.

Good Luck,
-Larry

UPDATE

I got some interesting email feedback from this blog article.  The article was generally geared towards somewhat mature startups / tech companies.  Fledgling startups in the early phase need to sprint to the point where they have customers and technical debt is a necessary evil.  The prettiest code ever is useless if there is no one using the product.  As time goes on and customers come in, you need to start paying down debt.  It’s kind of similar to processes – at first you will be horrible with process but as your teams grow and the company becomes real you will need to keep improving until everything is seamless.  Just as a warning, some bad technical implementations can actually get exponentially worse if left alone for too long.