Technical Debt is a new concept in computer programming that deals with the extra development work associated when code that is easy to implement in the short run is utilized instead of developing an optimal overall solution. Use Technical Debt in the context of refactoring in the field of extreme programming. Refactoring or restructuring existing code is part and parcel of the development process in computer programming. Refactoring is not the result of poorly written code but is based on understanding the problem, then finding an effective solution to the problem.
Technical Debt is also known as Design Debt.
Bugs during a software release
The traditional software program is released in phases: alpha, beta, and golden master. With each phase of release new features are built in, and remaining issues left over from the last released are addressed. The development cycle hits "alpha" when each and every feature is implemented and ready for testing. We reach Beta when enough bugs have been fixed to satisfy the customer, and he gives an adequate feedback. Unfortunately, while the team is busy trying to fix enough bugs to reach beta, new bugs appear. It's a classic case of whack-a-mole: try to fix one bug, and two more pop up. Ultimately, the release hits the golden master milestone where there are zero open bugs, achieved by fixing some known issues, and procrastination of the rest to the next release.
Procrastinating on bugs
Always deferring the problem of bugs to a later date that requires fixing is a wrong way to make software. As the bug count grows, handling it becomes increasingly tough–resulting in a vicious death-spiral of
technical debt. The matter worsens as schedules get derailed since coding around the bugs slows down development. On the other hand, customers are experiencing death by a thousand cuts caused by defects not fixed. As a result, some of them will leave you.
Reducing technical debt through Agile
Agile introduces quality into the iterative development approach. Consequently, the team can deliver a consistent quality product release after release. Traditionally, “done” means good enough for Quality Analysis teams to start. The problem with this line of thinking is that bugs or software defects creep up early in the release cycle and continue to cause trouble. So by the time QA gets their hands on it, the product is filled with defects. Agile Teams, however, express “done” as ready to release which implies the developers do not have to move to the next feature until their current product is with the customer.
Automate Bugs Away
When you observe a defect in the software, ensure to add an automated test that demonstrates it. After the problem is solved, rerun the test to ensure it passes. This forms the foundation of test-driven development which is a time-honored mechanism of controlling bugs in the system. Consequently, it also leads to spreading quality in agile development. Please
visit here learn more.
