1. 16
  1.  

  2. 7

    I like the idea of taking one day in the week to explicitly improve the codebase without any pressure to deliver new features!

    At my current job we have leadership who understands the importance of getting rid of tech debt - we have “cycles” where we first implement lots of features, and then a period where the team can spend their time on improving the codebase as we see fit. This works just as well, or maybe even better because you have extended periods of time where you can focus on big refactors and other improvements.

    1. 2

      I ran technical operations at an e-tailer years ago. December was always frozen for the Xmas sales rush but Q1 was always scheduled for annual updates. We’d upgrade Linux, mysql, redis and other “big” pieces of infrastructure so the annual cycle was predictable to the whole team. Outside of that quarter, the infrastructure would be stable for the rest of the year.

    2. 7

      At a previous job, we also tried instituting regularly-scheduled “fix-it” days where the whole team was expected to set aside their feature work and address tech debt.

      It didn’t really work well.

      The main failure mode was when a given developer wanted to avoid context-switching. If fix-it day happened to fall in the middle of implementing something complex, it turned out to be no fun to switch gears and then have to figure out where you left off.

      The other failure mode was that not all tech-debt tasks fit cleanly into one day. So you then have to decide whether to carry them into the regular work week or stash your work in progress on a branch somewhere and hope it doesn’t get too stale or too hard to understand by the next fix-it day.

      The general idea of setting aside time for technical concerns is a good one, but I think it works better when it’s less rigid. Agree that you have, say, a 10% time budget for this kind of work, but it’s up to the team whether that 10% is spent piecemeal or saved up for larger efforts.

      1. 2

        Good software management is good people management. I read articles like this and think - could I have instigated this change? I doubt it, makes me think I’m in the wrong job…

        1. 6

          I had the opposite reaction. I thought this had a lot of red flags suggesting the environment is horribly micromanaged. For example, having to convince external stakeholders not to schedule feature work on specific days — in a healthy, high-trust organization, that doesn’t even make sense as a concept because it’s up to the development team to arrange their work schedules to meet agreed-upon delivery dates.

          1. 1

            Fair comment, I took that to mean the realities of having users and customers - something will always crop up and attempt to squeeze in for the next release, cycle etc.