[Da Nang Scrum Breakfast] Dealing with Technical Debt

Editor's Notes

• #3: Software is eating the world You can find cars, phones, houses, aircrafts, and lot of devices we use in our everyday lives that are controlled by some type of software system. Now that everyone is aware that software has indeed eaten the world, we need to understand why technical debt is eating software http://thinkapps.com/blog/development/technical-debt-definition-importance/
• #10: Anyone who are using Credit card?
• #12: Financial debt is a silent killer Financial debt hides problems and leads to other problems
• #21: If you Google the term “technical debt,” I’m sure you will find many good definitions, descriptions, and explanations. Let me explain the concept of technical debt using a kitchen metaphor.   Imagine that you are an excellent cook. It’s Friday night and you have invited some friends to your place for a dinner party. You want to prepare a delicious meal. But, at the same time, you want to spend as much time as you can with your guests. When dinner is ready to be served, you decide to leave the kitchen without cleaning up and go back to your friends. The next morning, you wake up and want to make a quick breakfast before starting your day. The kitchen is a mess from the previous night’s meal. But you woke up late and don’t want to lose the whole day by doing a deep clean. http://thinkapps.com/blog/development/technical-debt-definition-importance/
• #29: The big difference, however, is that financial debt is usually relatively stable, whereas technical debt increases exponentially over time.
• #31: That’s an example of how debt can be a good thing
• #32: http://logz.io/blog/technical-debt/ https://www.excella.com/insights/good-technical-debt-vs-bad-technical-debt http://thinkapps.com/blog/development/technical-debt-definition-importance/
• #33: There’s no one-size-fits-all answer. I can’t give you a specific number in hours or days or even weeks.
• #36: The higher the quality, the lower the technical debt that you have to pay and vice versa. This choice usually allows teams to run a 100m sprint and boost their short-term productivity to quickly deliver customer features. If they don’t get back as soon as possible to improve the quality, however, future changes that they will need to make to that part of the code will be more expensive. And the next time they have to fix something in the code within a tight deadline, they will be imprisoned again in the same cell. They will not have the time to properly refactor the code and will add some more technical debt. And it becomes a vicious cycle that never ends.
• #37: Test suites are the safety pillow for every software system Increase in testing If the team does the same tests again and again on every release or testing takes too much time, the debt seems to be in critical level.
• #40: Developers sometimes seem to consider documentation to be hard work Partially agree with those who prefer writing clean and readable code rather than comments and documentation But, that is only one side of the coin. You don’t need to keep every little piece of the system updated but a document presenting the overall architecture and possible integrations should always be available Knowledge debt, only 1 person know a feature/implementation deeply
• #41: Give example, admin tool Last but not least, there is a type of technical debt known as defect debt. Defect debt describes the known defects that are not yet fixed because they are low priority, low severity, or there’s a known work-around. Some other cases include defects that have been reported but are rarely reproduced or are reproduced only under extreme or corner cases. Sometimes defect debt is computed as part of the design debt. But in some cases, it’s better to have a clear picture of the defect debt on its own, such as when you need to make important decisions about the future of a product.
• #49: The first step is to register our debt. Whenever we make a decision to take a shortcut or a quick and dirty approach, we need to log our decision and add it to our technical debt backlog, along with an estimate of how long it would take to fix. The estimate of course only makes sense if we are going to pay the debt off immediately. Usually, the longer we wait, the longer it will take to apply the fix and our initial estimate becomes invalid. Our technical debt register provides visibility into the prudent and deliberate debt decision we are making and when we plan to pay them back.
• #50: When faced with different types of debt, where do we start? Once again, it depends. Does the team know how to write tests to increase code coverage? Does the team know how to reduce complexity? If not, come up with a training and coaching plan. Does the team understand the rules they are violating? If so, start there. How about removing duplication and refactoring? Where to start is going to depend on the team’s skill sets and level, but the key is to put a plan in place and execute on it. Don’t quickly jump to the most complex class. Remember, there are long-term debts and short-term debts. We want to first reduce our short-term debt which is usually like credit card debt. This kind of debt has the highest interest rate. In code, this means we want to tackle first the classes that are constantly changing the most. The more changes we make the more interest we pay. If we have a class with no test coverage at all or one that is very complex but is never or rarely modified, we need to leave it alone for now. Consider it a low-interest debt and focus on the higher interest debts first.
• #52: What about debt in our existing code base? And what about the inadvertent debt that we might be piling on without knowing it? For that, we have to inspect and assess the level of existing debt we have and also register it. Luckily, there are tools that help us do that. SonarQube helps us assess debt across multiple categories like duplication, rule violation, code coverage, complexity, documentation, etc… and provides us with multiple ways to visualize the debt and plan on how to pay it back
• #61: What about debt in our existing code base? And what about the inadvertent debt that we might be piling on without knowing it? For that, we have to inspect and assess the level of existing debt we have and also register it. Luckily, there are tools that help us do that. SonarQube helps us assess debt across multiple categories like duplication, rule violation, code coverage, complexity, documentation, etc… and provides us with multiple ways to visualize the debt and plan on how to pay it back