TODOs, FIXMEs and a ‘window fixing’ wall

Agile software development places a lot of emphasis on prioritisation of work and elimination or deferral of anything which is not needed right now. An obvious advantage of this is that important stuff gets done quickly, but a less obvious disadvantage is that deferred work can pile up like snow before a snowplough. For a long-running project, the effort to keep “pushing” these deferred activities can become a significant task in its own right.

The Pragmatic Programmers wrote:

Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.

While this is fine as a principle, there will still be times when edge-cases, uncommon modes of operation, laborious work-rounds and generally less valuable aspects of a system should be deferred, even though there is a sense that they will need to be improved later. The question arises of how to best represent and remember these issues so that they are not accidentally lost.

Some development IDEs and other tools incorporate in-code annotations such as TODO or FIXME, and almost every programming language supports comments, where such notes may be paced for more manual processing. These can, however, be tricky to find if you don’t already know where to look, and an apparently obvious note can quickly lose context and usefulness as developers move to focus on other work.

Mark Needham recently wrote of his experiences with a ‘window fixing’ wall.

A project I worked on recently tried a section of a card wall for “issues”, but these languished in a fog of “somebody else’s problem”. We got rid of that and replaced it with a section to collect issues for the next retrospective, but even that has become less used as the project progresses.

Inspiration for a solution might come from another post from mark Needham: “Pain Driven Development.” Although this article emphasises other aspects of agile process, the essence of the idea seems to be that the things that actually get done are the things which cause the most “pain”. Perhaps if we can find a way to convert theoretical “broken windows” and other incomplete work to a sense of “pain”, they will naturally be addressed as part of the normal intuitive prioritisation process.

Has anyone managed this?