Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Re: Backlog of technical tasks?

Expand Messages
  • Jim Schiel
    I would add that having a significant technical debt on legacy code is probably very common and I think I ll add something to George s thoughts that were
    Message 1 of 55 , May 1 4:55 AM
    • 0 Attachment
      I would add that having a significant technical debt on legacy code is probably very common and I think I'll add something to George's thoughts that were probably behind the pattern he recommended. "Pay down" (were we to give it a name) should be done with a lot of attention given to the business value derived from completing certain technical debt stories. There's a lot of risk associated with touching (changing) code. The old adage: "If it ain't broke, don't fix it." might apply here -- if the legacy code works, consider carefully whether or not there's sufficient value (i.e., reduction in risk) in changing the code to complete a technical debt story, and, as George said, if you can do it in combination with a value-adding feature story -- great!
       
      I suppose this also reintroduces the concept of "good enough" that Jim Fosdick talked about yesterday. That being said, I'll stop here rather than risk repeating someone else.
       
      Jim Schiel
      CST, Danube Technologies
      On Thu, May 1, 2008 at 7:14 AM, George Dinwiddie <lists@...> wrote:

      MacKilby wrote:
      > --- In scrumdevelopment@yahoogroups.com, "Jim Schiel" <schiel@...> wrote:
      >
      >>> Bottom line -- technical debt is no different than anything else
      > on the
      >>> backlog. Don't treat it like a second class citizen -- it's always
      > going to
      >>> be there and everyone should get used to it being there.
      >>>
      >
      > Agreed... and now let me share more of the story that prompted the
      > question.
      >
      > When I implied a large technical debt, I was thinking of those
      > companies that had legacy code bases to deal with.

      In that situation, I recommend AGAINST scheduling paying down technical
      debt as separate items from the user stories. Not only does the
      work-without-new-functionality look bad to the Product Owner, you may
      find yourself cleaning up code that never needs to be touched.

      I've always found it possible to refactor and pay down technical debt in
      the course of adding new features. As you touch legacy code, you leave
      it a little cleaner and easier to use than it was before. One big
      benefit of approaching it that way is that you're cleaning precisely in
      the areas that are most affecting the new work.

      I will grant that it takes some time to learn the skills of cleaning up
      as you go, but I'd also posit that if you don't learn those skills,
      you're likely creating new technical debt in your new code by not
      refactoring it to be as clean as possible before declaring the story
      done. Treating the paydown of technical debt as a project, with some
      upfront design followed by implementation doesn't seem to teach these
      skills. Treating the paydown of technical debt as a tax on everything
      you do, doing a little bit anytime you touch the code seems to produce
      the skills to not only reduce old debt, but avoid adding new debt.

      - George

      --
      ----------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------


    • Michael James
      ... Yes, and there s really no contradiction between these approaches once we see the Sprint Planning Meeting as a good faith negotiation. Normal technical
      Message 55 of 55 , May 4 3:45 PM
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, "Jeppe N. Madsen" <jeppe@...> wrote:

        > I've been skeptical about putting technical tasks on the backlog for
        > many of the same reasons listed in this thread. I think we should
        > make "the world a better place" one step at a time, by refactoring the
        > code as it's touched due to new requirements.

        Yes, and there's really no contradiction between these
        approaches once we see the Sprint Planning Meeting
        as a good faith negotiation.

        Normal technical debt should be paid off through
        the definition of "done" for product feature stories.
        Things like this might include refactoring away
        duplicate code, complex conditional logic, long
        modules, nested "catch" blocks, poorly named
        methods and classes, normal database schema
        changes, normal upgrades to third-party
        libraries....

        > If there really are technical debt that hinders
        > progress, this is an impediment.

        Yes, when progress on multiple fronts is impeded
        by severe fundamental underlying debt issues
        (often at the infrastructure level, like platform
        changes, major database changes, major library
        changes) it may be useful for the team to make
        it visible in the product backlog as a step toward
        breaking the repayment work into manageable
        pieces. Anyone can add items to the Product
        Backlog.

        Of course we still expect some feature delivery
        every Sprint.

        --mj
      Your message has been successfully submitted and would be delivered to recipients shortly.