1. 27
  1.  

  2. 4

    My first reaction: this is brilliantly summarized. I admit I’m going to have to step back to offer critical feedback.

    1. 3

      I’m glad this is being studied! One thing that doesn’t seem to fall into any of these categories: rewriting code late in development in response to shifting feature sets, e.g. “Marketing decided, post-beta, that we have to have feature X.” It’s not really Building The Wrong Feature or Rework because it happens before release.

      In the 90s I once worked briefly for a startup where the “visionary” CEO kept switching on a monthly basis between pushing us to finish ASAP, and announcing a critical new feature the product absolutely had to have. It was kind of comical.

      In another project, there was a late change to a fundamental aspect of the networking algorithms. Several years later my code was still littered with technical debt in the form of crafty sections of code that had been hastily altered in inelegant ways to make this change in time for GA.

      1. 3

        I don’t see why “building the wrong feature” should exclude stuff built before the release. In fact, the perfectly wasteful product never makes it to release; then everything was a waste!

      2. 1

        I often wait a while and do user support before starting a particular task to see what actually needs to be done. This gives a chance for useless things to become apparent before I waste a bunch of time doing something that is gonna get dropped anyway. Important problems tend to come up a couple more times and working the help desk for a while before diving in gives me a better perspective on what is gonna matter to the end users.

        I swear I’m not procrastinating, I’m actually researching prioritized requirements!