tag:blogger.com,1999:blog-5028009537158799436.post7756099093873995206..comments2023-07-10T04:50:03.236-07:00Comments on Building Real Software: Are bugs part of technical debt?Jim Birdhttp://www.blogger.com/profile/17371102366836131341noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-5028009537158799436.post-63006685976222583582012-12-13T07:23:19.541-08:002012-12-13T07:23:19.541-08:00Seems overly complex. Technical debt represents f...Seems overly complex. Technical debt represents future work that the technical team will need to do (with high probability). I don't why recording it as a bug is something that makes that different.<br /><br />When we talk about technical debt we usually refer to work where the benefit to the user is not evident to someone outside the team or is not imminent. This is contrasted with a bug fix impacting something the user sees or a new feature providing some new functionality to the user. Both are debt though. Both incur "interest" in that dealing with them later is going to be more expensive.<br /><br />Technical debt is the silent killer. It is the work that needs to get done but isn't and when it's not done it will slowly choke the project.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-12258477515907318962012-12-13T06:30:27.142-08:002012-12-13T06:30:27.142-08:00@Anonymous, some teams might have good reasons for...@Anonymous, some teams might have good reasons for not fixing every bug that's ever found, as I've argued before in a post on Zero Bug Tolerance: http://swreflections.blogspot.com/2011/02/zero-bug-tolerance-intolerance.html<br /><br />Other teams deal with bugs consciously or unconsciously like other kinds of debt: they take a bug load on because they are trading off fixing bugs with something else that is more important to them at the time, usually hitting a deadline. My point here isn't that this is a good practice, but that it is reality in many shops. <br /><br />Big older systems often have bugs that haven't been fixed for some reason. If the team, or management, or whoever is paying for the work, are pretending that these bugs don't need to be fixed, they become debt. <br /><br />"Lack of documentation" is interesting. I can see out of date or incorrect documentation as technical debt, if again you aren't planning to do something about it or haven't done anything about it for a while. Otherwise errors in documentation are defects. But missing documentation? How does somebody judge what documentation is or isn't needed for a system? How do you measure the cost or risk of not having more documentation, and what kinds of documentation?<br /><br />This is another example that technical debt means different things to different people.Jim Birdhttps://www.blogger.com/profile/17371102366836131341noreply@blogger.comtag:blogger.com,1999:blog-5028009537158799436.post-61825626263177562422012-12-13T05:51:17.682-08:002012-12-13T05:51:17.682-08:00"But what about defects that you've found..."But what about defects that you've found, but that you've decided that you’re not going to fix"<br /><br />I have no idea where you work but that wouldn't fly in any shop I've found myself in. Bugs are bugs and must be squashed.<br /><br />Technical debt is bad architecture, lack of documentation and lack of automated tests.Anonymousnoreply@blogger.com