{"id":188,"date":"2009-09-23T15:16:00","date_gmt":"2009-09-23T15:16:00","guid":{"rendered":"https:\/\/caroli.org\/en\/respect-the-elder-bugs\/"},"modified":"2020-01-10T19:45:26","modified_gmt":"2020-01-10T22:45:26","slug":"respect-the-elder-bugs","status":"publish","type":"post","link":"https:\/\/caroli.org\/en\/respect-the-elder-bugs\/","title":{"rendered":"Respect the elder bugs"},"content":{"rendered":"

Billy (below) is a known old bug. Old enough that it got a name and is well known to the development team.<\/p>\n

\"\"<\/a>
\nBugs, or defects in your software, are not to be treated as pets! Make sure you close bugs fast. Do not get used to bugs.<\/p>\n

Agile software development (as typically is the case in the software industry) does create bugs. In fact I came across new Agilists that were surprised because Agile development practices also create bugs; in fact, I have seen more bugs (I am not talking about defects in production) in Agile development than in more traditional development.<\/p>\n

But what I expect from a well-working Agile team is that:<\/p>\n

    \n
  1. The number of bugs in production is low<\/li>\n
  2. Bugs are closed very fast<\/li>\n<\/ol>\n

    Test Early and Often<\/h3>\n

    Agile development practices such as continuous integration, test driven development, and automation facilitate the quick detection and elimination of bugs. Your customer tests (test validating the customer requirements) will detect any addition or change that breaks an existing test. Your developer tests (tests validating the design of your application) will detect anything that breaks the expected design and behavior of the application.<\/p>\n

    Disclaimer: for smaller teams, this will be as simple as identify and fix the recognized problem. But for very large teams, it might get a little more elaborated, and a bug is created to track the issue (at times, the issue itself is that there was no automated test).<\/p>\n

    Scaling Agile<\/h3>\n

    Scaling Agile has a few nuances to it. And bug management and resolution is amongst the development practices that require special attention for a large Agile team. From my experience on a large Agile program, I second the importance to classify bugs by priority and severity.<\/p>\n

    Elisabeth Hendrickson wrote a very good article about it: Arguing Apples and Oranges<\/a>.<\/p>\n

    But even with good bug classification and management, I noticed a few old (pet) bugs living in my large Agile program.<\/p>\n

    Consider the program had an average rate of 100 new bugs per week. Don\u2019t be alarmed, it is a huge program. Imagine 100 developers continuously integrating code for 200 user stories per week. And an average rate of closing 100 bugs per week.<\/p>\n

    The depicted scenario can be of a very healthy Agile program. For instance, a small period of regression ensures the production readiness for the system. As Regression I mean the period allocated to stabilizing–fixing the bugs– the next releasable artifact; not adding new features.<\/p>\n

    But how is this sample program creating old pet bugs?<\/p>\n

    Low priority, low severity bugs. These are the bugs that can live a long life.<\/p>\n

    If the reasoning for deciding the order to attack the bugs only considers severity and priority, you might be creating pet bugs. I did recognize a few elder pet bugs (for this reason) in my large agile program.<\/p>\n

    My recommendation is to adjust your bug triage formula. You should consider severity, priority, and the age of the bug.<\/p>\n

    I am sorry Billy (my old pet bug). Even though you were low priority and low severity, it is being embarrassing to have your small \u2013almost inoffensive\u2014existence in the system. I am sorry, but you have to go!<\/p>\n

    <\/div>\n","protected":false},"excerpt":{"rendered":"

    Billy (below) is a known old bug. Old enough that it got a name and is well known to the development team. Bugs, or defects in your software, are not to be treated as pets! Make sure you close bugs fast. Do not get used to bugs. Agile software development (as typically is the case […]<\/p>\n","protected":false},"author":1,"featured_media":903,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[1919],"tags":[774,856,866,868,668,778,858],"inception_activities":[],"colaboradores":[],"class_list":["post-188","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile-culture","tag-agile-en","tag-bug-en","tag-bug-triage-en","tag-governance-en","tag-large-agile-project-en","tag-management-en","tag-scaling-agile-en"],"_links":{"self":[{"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/posts\/188","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/comments?post=188"}],"version-history":[{"count":0,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/posts\/188\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/media\/903"}],"wp:attachment":[{"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/media?parent=188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/categories?post=188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/tags?post=188"},{"taxonomy":"inception_activities","embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/inception_activities?post=188"},{"taxonomy":"colaboradores","embeddable":true,"href":"https:\/\/caroli.org\/en\/wp-json\/wp\/v2\/colaboradores?post=188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}