Technical Debt

The wiki definition for Technical debt says "Implied cost of additional rework caused by choosing an easy solution".

No body ever plans to add technical debt , it gets added as part of the culture of the organization. In the present world of speed to market teams are working under huge pressure of timelines and this is causing people to take short cuts to deliver in time. Thats why I like the motto "you own your ops". That way we will be more focused on self-service, monitoring and self-healing aspects instead of dev teams throwing over fence to the operational side of the IT.

Through every phase of software development life cycle we are adding technical debts. while developing stories we may not have time to investigate all possible scenarios. We are not able to invest enough time analyzing all data decisions. So, we might have taken 80/20 approach and ended up with 20 % technical debt right off the bat. Then during design we don't have time to develop API based framework , following best approaches and patterns. There we added another 20% of technical debt. While developing the code we took the fastest possible approach instead of maintaining secrets in key store, making components loosely coupled etc.,

Here we add another 20% technical debt. With all other phases we will keep adding technical debt. 

Someone I was working with in the past said, the only reason for bugs in software is code 👏

So the day application moves into production is the day it has technical debt. Keep your images up to date, refreshing code for best practices will eliminate lot of operational chaos and technical debt.

The challenge is with applications that are NOT touched frequently. Who cares about that technical debt. What is the motivation for them to move away. The only best possible approach is to tie the maintenance cost with business budget. That way business will have motivation to kill some of the less used products and invest in the growing products. If we allocate some default budget to operations , it will always keep growing year over year. At one point you will have to spend more money on operations than development.

Be ruthless in killing the apps/products that are less used. The only way we can do that is measuring the usage and NPS scores. If a product meets the threshold of less usage and having bad NPS scores invest time either to move the functionality to some other app or re-architect for current world use cases. Remember "You can only manage what you can measure".