Making Technical Debt Visible to your Team
July 12, 2015
The common reasons of every software has bugs are complexity and uncertanity. It doesn't matter were user requirements not clear enough or 3rd party component was used. It is hard to predefine how your software will behave on production with real data, how your software will interact with the environment and what will be impact of real usage scenarios.
Here are common issues you will find on production in most of cases:
- Unhandled exceptions in application server
- Slow queries
- Low level of transactions per time interval
- High CPU usage on specific URLs
- Unexpected behavior users are noticed
All these issues are not critical, but very harmful for the reputation of your service because it shows its low quality. Low service performance forces you to allocate more resources, so use it effectively. Corrupted data is produced because of hidden issues and unhandled exceptions. Users don't like report issues, it is stressful to them and takes time, so your team will never know about these issues.
You say strong quality control procedures are the key. Your team has unit tests, automatic performance and functional tests and manual exploratory tests. Also you know there is no 100% tests coverage across all components of your service. You know that automatic tests are expensive. Thus you can't physically check all scenarios and preconditions with all possible environments, therefore bugs still exist in your service. It seems you can apply all of your team's efforts on testing and find the vast number of issues once. But applications are evolved permanently, so new features are added with new bugs, unexplored context is appeared again when using 3rd party libraries or middleware your team never used before. That is why your technical debt is increasing permanently and it means you have to reduce the debt systematically on the daily basis.
Fortunately, there are couple of ingredients to make your development process be focused on cutting technical debt:
- Don't rely on customers, they will not send you bug reports with all details you need. Use exceptions monitoring instead. With the help of exception monitoring you can catch unexpected behavior and unhandled exceptions at any level of your application stack. Just inject exception handlers into your code. Your team will have very detailed bugs reports automatically with context and stacktraces.
- Make all required performance indicators controllable. Think about queue lenghts, cache size and hits on it, transactions per seconds and others. Collect the metrics automatically with help of modern application and server monitoring tools. Sometimes you'll have to develop your own scripts to do required task.
- Provide help desk via email or web site to gather feedback and resolve challenges your customers are facing with.
Only this way your team will have clear understanding of hidden and visible issues related to your service and be able to fix them proactively. This may seem too complicated to bring these ingredients into real life. Have a look at DevOpsBoard which is ready to use solution which holds and visualize exceptions, monitoring alerts and customers feedback related to your service on a single task board. Just connect exception handlers to DevOpsBoard, plugin your favorite exceptions or applications monitoring tools using webhooks and connect built-in helpdesk application to your domain. While using DevOpsBoard every team member is involved into activities of technical debt reduction now.