When we bought our house, we designated one of the rooms as “ the computer room”. It was kind of small office, with a couple of book shelves. Then, with the children, we’ve added more cupboards and shelves and computers. It was no longer the computer room, it was a storage room.

“Where is X?”

X is found most of the time at the storage room.

And boy, we’ve gathered a lot of Xs. Because once you have space, the decision of keeping or getting rid of something, doesn’t even come up. When it does, the answer is usually “well, maybe someone will need it someday”. And we keep it. As we keep oodles of Xs and Ys.

There’s something magical about storage room: It may be limited, but seems to have infinite volume. There’s a lot of stuff in it, but I probably won’t be able to find any of it. With all the mess, things stacked on top of each other, papers to shred and/or sort out, cables of all types that I just may need one day, I know that if I need something it’s probably easier to buy,  rather than search for it.

In knowledge work, we usually keep stuff in virtual places. And there’s no limit to those.

For years I’ve worked with different bug reporting systems. Those things have infinite space. So it’s makes sense we should document every bug properly, because some day we’ll need the documentation for resolving it.

Not all bugs are created equal. The minor ones, the ones “we’ll fix if we have the time” usually don’t get fixed. There’s a reason they are minor bugs. But we put the same effort into documenting high risk and low risk bugs.

It gets even funnier.

We document the bugs, because we want to have all the data for the programmer to fix it, right? So what happens when a major bug occurs? We quickly call someone to see the bug happening before we document it, because we don’t want them to miss it happening live. So in the important case, we’re documenting after we’ve shown the problem, and in the regular case, we document something that may not be fixed.

But the bug doesn’t just go away. Every bug in the backlog is waiting to be upgraded to “work in progress”. But in order for the bugs to be approved, they need to be triaged. And if bugs don’t get over the hump the first time, they will be re-discussed and re-reviewed, usually by more than one person, and usually more than once. What a waste.

Fascinating

Here’s a strange premise: What would happen if your bug systems was a limited resource? If it could contain no more than, say, 30 bugs?

Let me make it even worse: What if the total space for features and bugs in your backlogs were a total of 30?

You’d really need to make a decision, to really forget a bug or a feature idea.

Prioritize.

As a product manager, I decided that there was too much information, ideas, bug reports and feature requests floating in different locations. So I limited the list. Some people were terrified.

“What will happen if we’ll need the information on that bug?” – If it’s a real issue it will come up again.

“But we won’t have a full picture!” – That’s a risk I’m willing to take, as long as I don’t have to re-read a bug description for the 15th time.

Today’s ability to store infinite pieces of information is in contrast to how our puny brains work. It needs small pieces of data to manage. It needs to focus, not disperse.

We don’t need more space, we need less.

Spock would agree.

PS: Now we’re looking for a new house, with rooms for the children, and an office. Oh, and maybe there’ll be a separate storage space too!