Every software project has a backlog of enhancement requests, unimplemented features. It may be explicitly tracked in a database, or perhaps just a sort of informal consensus among developers. Whether officially acknowledged or not, it exists.

The backlog is typically sorted, acting as a priority queue, perhaps from P1 to P5. Or colloquially, from “must have” to “absolutely not”. (Even closed, rejected items still exist. Nothing is closed forever.) It is common to think of these as absolute priorities, with a fixed number in each bucket. Finish all the P1s, and then there are no more, only P2s and below. I will argue that this is not what typically happens. Instead, the backlog is stack ranked, with a fixed proportion in each bucket.

One consequence of this is that unless a project implements literally every imaginable feature, there is always a next up, a top priority ER waiting in the wings. Also, it’s clear that no project is ever finished. Development has a momentum all its own, continuously popping the top ER off the stack. Done? Next. Done? Next.

This tendency can be countered with some discipline, but it’s difficult to maintain. Let’s finish all the P1 and P2 ERs and then stop. Done. But the P3s haven’t disappeared, and now they are at the top of the stack. New users, managers, market forces are exerting constant pressure. They weren’t here when we decided to stop after the P2s. All they see is a stack with an unimplemented ER waiting at the top. Blink and the backlog will rerank itself, and now you’ve got P1s again.

Unimpeded, this results in ever worsening software. Some of those P5 ERs are truly terrible ideas, but after digging through the upper layers, now they become the best available idea. I think many software developers have some idea this is happening, perhaps only subconsciously, and the instinctual reaction is to bring in more ERs.

When the stack gets thin, we branch out, looking for new ideas. Anything to keep the bad ideas stuck down in the P5 tranche. But good ideas are fairly rare, and so many of these reinforcements are only mediocre. Still better than awful, right?

Resolving this dilemma requires recognizing it and maintaining precise definitions. Given 100 ERs, there’s a big difference between implementing the top 20 and the top 20%. If you find yourself trying to pick the one best feature from a list of five, you’ve gone astray. But sometimes we may not realize this is happening until we’re in this situation.

Certainly, lots of people suggest software should be done at some point. But lots of software seems to continue development after it should be done. Part of the problem is probably that we don’t all agree on what done means. Another part of the problem may be that we’re looking in the wrong direction, even when we do agree. I’m not sure this is exactly literally what’s happening, but it seems something like it is happening.