Know your Technical Debt and move forward in spite of it!

In the software world, “Technical Debt” is a term used to describe the ramifications of your decision making during development. When you have functionality you need to add to your program or system, you see two ways to do it. One way is quick and dirty – you are sure it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. There are pros and cons to both methods.

Good Enough

“Technical Debt” is a metaphor developed by Ward Cunningham. In this metaphor, doing things the quick and dirty way sets us up with “Technical Debt”, which is similar to financial debt. Like financial debt, the “Technical Debt” incurs interest payments, which come in the form of the extra effort we have to do in future development because of our initial design choice. We can choose to continue paying the interest or even make the debt worse buy never going back to fix it, or we can pay down the principal by restructuring the quick and dirty design into the better design with each release. Although there is an opportunity cost to pay down the principal, we gain by reduced interest payments in the future.

Many people in the Internet Marketing space, myself included, fall into the trap of trying to make everything perfect before releasing a product for sale. This method theoretically leaves you with no “Technical Debt”. If you are prone to this it shows itself in the constant tweaking of a product, the need to learn new strategies before the first one is tested or just plain procrastination. The need to avoid Technical Debt can result in never releasing your product, or by the time it is released it is obsolete.

In many cases it may be sensible to take the quick and dirty approach. Just as a developer incurs some debt to hit an important deadline, a business or Marketer may decide to incur a debt to test a business plan or hit a window of opportunity. In most cases this is a better decision initially as you won’t waste valuable resources and/or time before knowing if you have a winner.

My suggestion is to understand what your “Technical Debt” is, know what trade-offs you are making, what you may want to fix in the future and move forward quickly. Once you have released your product, you will get feedback from your customer and then you have the option of going back to fix your debt as you enhance your product or service or completely change direction. As you get feedback and valuable data sooner, the benefits are obvious.

What “Technical Debt” could you happily take on to get that product done and up for sale? My advice would be to do what you can to speed up your development so you get feedback sooner. You can then decide how important those changes really are.

Tags: , , , , , ,

Facebook Comments: