Most people recall the phrase from the Movie, "Water World", that "dry land is not a myth". It was considered a myth because no one had seen land while living on a "Water World". If you work in an environment where writing software is equivalent to "running a well greased machine" then the term, "technical debt" may not resonate, but that does not mean that technical debt is not being compounded. Over time any debt starts to complicate our lives. On the other hand, some amounts of debt are normal as long as there is a plan for handling it. For instance, I need to buy a new transmission for my truck. I might use a credit card to purchase and have it installed, and since I do not have the money right then, I will charge it to my credit card and pay it off within the next couple of months. The plan for handling any debt is what is necessary for making sure debt remains relatively low.
So what is technical debt? Well as mentioned earlier, some debt is ok which I will explain later, but bad technical debt occurs when there is a lack of strategy for building and maintaining technology and it starts effecting the delivery of software. Just because there is a team of developers and software is being written, does not mean it is being done correctly. Technical debt also effects how we estimate software tasks and how effective we are for deploying software. IT companies and departments incur it daily, however just like the example about the truck transmission, it is necessary to sometimes incur technical debt in order to provide a "minimal viable product" (MVP). This means a developer might take shortcuts in their code to get a software product out to customers, and as long as there is a plan to fix the debt, it does not continue to incur to the point that over time it becomes a problem.
Avoiding technical debt is all about making sure you have effective processes in place for writing software and a strategy for maintaining future software changes. These processes are very important for keeping estimates and deadlines for delivering software. Just as you may monitor your checking account, it is important to monitor the technical debt your development team accumulates by doing the following:
1. Talking with your team and other departments about recommendations around development. There should always be transparency about what others are building. "Silo software development" is equivalent to someone who is a bad gambler and is headed to Las Vegas.
2. Create processes around delivering software. These processes should be measureable and conducive to delivering new products to customers or the business effectively. Do not create processes for the sake of creating processes as this can promote technical debt.
3. Measure the effectiveness for existing processes as these may need to change over time. This is done by training the development team on effective ways to estimate tasks. Identify reasons for "sliding deadlines", and make sure that the processes include everyone, including other departments who play a role for making sure software gets delivered, like infrastructure and testing groups.
There is bad and good technical debt, and it is all relative to the amount of debt your software team can handle. Just like financial debt, it must be managed by planning out how to reduce the amount of debt incurred. To learn more about the different types of technical debt a software shop encounters and ways of reducing it please contact me.