{"id":272,"date":"2011-03-13T14:15:12","date_gmt":"2011-03-13T21:15:12","guid":{"rendered":"http:\/\/10kdev.ivystreetinc.com\/?p=272"},"modified":"2011-03-13T14:15:12","modified_gmt":"2011-03-13T21:15:12","slug":"when-its-in-dev-its-in-dev-dammit","status":"publish","type":"post","link":"http:\/\/10kdev.net\/?p=272","title":{"rendered":"When it’s in DEV, it’s in DEV, dammit"},"content":{"rendered":"

Last week I was faced with a dilemma I run into on projects that are just gearing up their process.\u00a0\u00a0 The dilemma may sound simple, but it this:\u00a0 when is it OK to log defects?<\/p>\n

Now some of you may think this is a stupid question and answer “ALWAYS OF COURSE!”\u00a0 But I heartily disagree.\u00a0 Because BEFORE we start logging defects, we have to ask the question:\u00a0 what are we trying to accomplish with this phase of of the software?\u00a0 If the software is still in DEV — that is, its no finished<\/em> yet, then what does a logged defect really mean?\u00a0 And who can the logging damage?<\/p>\n

OK, let’s outline what I see as the problem once more: Logging bugs on work that is in developer progress is a hindrance because it is not finished — the developer is still implementing the business requirements so bugs on this are basically moot.<\/strong><\/p>\n

On last week’s project me and the UI guy had to release something on the rarely-used STAGE server as a DEV server because we are also getting the who lifecycle environment up and going, and we had no proper development environment to deploy to and bang out our fleshing out and development of a major rearchitecture we are working on.\u00a0 Also, the data environment had not been refreshed in at least two years!\u00a0\u00a0 The UI gy started to ask the biz team to start banging on it but I said WOAH WOAH WOAH cowboy — hold on a minute.\u00a0\u00a0 We aren’t done yet!\u00a0 Logging bugs on an unfinished piece\u00a0 is like telling me that flour doesn’t tasted like baked bread.\u00a0\u00a0 The repurcussions for logging bugs out of context are this:<\/p>\n

    \n
  1. Time lost investigating bad data problems that are just dead ends.\u00a0 Like old\/out of context\/non-refreshed data.<\/li>\n
  2. Statistics that will be mined (out of a bug tracker) by people who do not understand the context — this is tantamount to lying with stats. \u00a0 Logging and “fixing” (basically finishing a story) bugs on unfinished software and using this to show how good\/bad people and processes are is very simply NON-OBJECTIVE and UNSCIENTIFIC use of crap data.<\/li>\n
  3. Team dynamics can be difficult when this happens.\u00a0 Mistrust.\u00a0 People holding things close to their vest.<\/li>\n
  4. If you are doing TDD or BDD, all your tests break up front.\u00a0 Seriously — you are going to log this as defects and fix them and close them as PART of your development of a new story????<\/li>\n
  5. If a developer has to worry about this QA process, then why should time even be wasted sitting with the state holder fleshing out say a screen, if they are just going to log the missing pieces or code plugs as defects?<\/li>\n<\/ol>\n

    See what I am getting at?\u00a0 Here are two more examples of this kind of probem — when to log defects — seriously impacted work on my teams at two different Fortune 50 companies in the last 10 years:<\/p>\n

      \n
    • At one place an engineer and I were developing<\/em> (with another remote team) the Hudson builds.\u00a0 We were trying to also normalize the IDE builds (i.e. build button actions), the in-IDE ant builds, and the Hudson maven\/Ivy builds.\u00a0\u00a0\u00a0 Developing<\/em> them.\u00a0 On a development server.\u00a0 But, the upper management saw fit to start sending out nasty “don’t break the build” messages over and over to everyone pointing at us core people.\u00a0\u00a0 It was nasty . . . we spent a ton of money setting of another system just to get out of this stream before we could deploy to the actual place we were supposed to develop this!!!<\/li>\n
    • Over 10 years ago I had a manger who had came from QA who literally would start logging bugs on our DEV server, waiting until we completed the feature, then close them.<\/li>\n
    • Another place we’d do screens (like I mentioned above) and if we dared release a small piece to our server, or our iteration was observed, defects would get logged on partially complete work.<\/li>\n<\/ul>\n

      I have some other examples but those are the major . . and now this at my current gig.<\/p>\n

      Some of you may think this is totally outlier but its not, not at all.\u00a0 Some of you may say “well why not just log everything?”\u00a0 And my answer is:\u00a0 have you worked at many places?\u00a0 Because if you have, you’d know the general attitude towards developers may be distrust — which is partly our own faults; you know, those cowboy coders who left everyone holding the bag.\u00a0\u00a0 And that stats can be used to show ANYTHING.<\/p>\n

      Case in point:\u00a0 I worked at a place where by the management team’s own measurement we pushed out more features than any other team, but they ignored the very stats that showed it, that they told us to use, due to a built in site bias (i.e. all of the management lived in another city).\u00a0 hahaha\u00a0 serious!!!<\/p>\n

      My advice is this:\u00a0 avoid situations where anything other than a rigorous process can be used.\u00a0 It just helps everyone out — it creates those proper buckets and behaviors.\u00a0 More feedback is better of course, but disallow in your Jira or whatever a bug log on DEV; or a metered bug log at worst.\u00a0 But crank it up in the true QA.<\/p>\n

      Most places have minimally three levels to thier bug flow:<\/p>\n

        \n
      • Pre-Release Defect Tracking:\u00a0 DEV to QA defect process — when code is released to QA, defects found, and code fixed and release.<\/li>\n
      • UAT Defect Tracking: QA to STAGE\/User Acceptance.<\/li>\n
      • Released Code defect tracking — code in the field<\/li>\n<\/ul>\n

        Each has a different scope.\u00a0 If we are true to the agile ideas then all of us can take part in each phase — that is, al of us as a team; BA’s, QA’s, DEV, Owners can give meaningful feedback.\u00a0 The power is in following a nice process and then re-evaluating that process.<\/p>\n","protected":false},"excerpt":{"rendered":"

        Last week I was faced with a dilemma I run into on projects that are just gearing up their process.\u00a0\u00a0 The dilemma may sound simple, but it this:\u00a0 when is it OK to log defects? Now some of you may think this is a stupid question and answer “ALWAYS OF COURSE!”\u00a0 But I heartily disagree.\u00a0 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/272"}],"collection":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=272"}],"version-history":[{"count":1,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/272\/revisions"}],"predecessor-version":[{"id":274,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/272\/revisions\/274"}],"wp:attachment":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=272"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}