This is from an earlier blog. I received several positive reviews so I thought I would share again as I have new followers and since we are about to begin a new year.
Technical health is a better term than technical debt when describing the principle of keeping software “clean”. Most of us care and understand the consequences of not maintaining good personal health. However, many of us today have run up large debt from school loans, home mortgages, auto loans, etc. Countries generally have huge national debts which continue to explode. It has become an accepted and normal part of life. So why should management care about preventing”technical debt” from growing bigger? It becomes easier to explain that it is essential to maintain our “technical health.”
One student suggested calling it “Technical Cancer.” This term more accurately describes the phenomenon where growing and unattended technical debt may ultimately “kill” the project. I prefer to be a bit more sensitive and use the term “Technical Health”.
We need periodic health check ups and take actions (medicines, lifestyle changes, surgery, etc.) to avoid a life threatening illness. Technical health implies “being managed”. The same should be true for our programming projects.
Our technical health diminishes when incomplete work is added into a programming project, and no resources are scheduled or budgeted to complete the work. Bad health habits include the introduction of defects into the system, lack of good documentation, poor system performance, not following coding standards and generally leaving unclean or untested code. Poor health is contagious when developers start practicing these bad habits on an accepted regular basis.
A friend told me “I feel fine and do not want to go to the doctor for a check up to learn that I may have a disease”. It is like the system where the original code was so poorly written that no one was willing to modify the section of code, rationalizing “if it is not broke, don’t touch it”. However, like your health, it introduces a risk into the system which could cause a costly disaster in the future.
Do not ignore the signs of poor health by lowering quality standards and accepting user stories just to increase an iteration’s velocity. On one software project, the system began crashing when the user executed a seldom used feature. The crash was the result of inadequately tested code inserted at the last minute before the release deadline. Unfortunately, the software was released without the defect being fixed and was later discovered by a large important customer. The illness had now been transmitted to others, creating potential harm to the reputation and future business of the software provider.
The best way to manage our technical health is to enforce and follow good healthy standards. These include coding standards, testing procedures, and documentation standards. In Scrum, adherence to a good definition of done and user story refinement process will help maintain your health. Think of it as good eating and exercise habits.
When planning programming projects, there is a trade-off on whether to add new features or schedule time to improve our current technical health. Personally, we choose by taking time off to exercise or go to a gym. We also schedule periodic vacations. Unless it can be proven that the health risk is high to the business, product management almost always chooses adding new features. Remind them that it is not just debt but may lead to cancer if left untreated.
Regularly adopt and improve your practices to maintain good “technical health”! And, I wish everyone good “technical health” for 2018 and beyond.
