Tabling Ideas

I once had an idea for a new user interface feature. It would inform the user about the health of their resource quota by showing a small indicator in the corner of the screen. The key to this component was that it was small, unobtrusive, and visually intuitive. Colors and icons would do most of the work in indicating any change in health. It was never implemented. Was it a valuable feature to have? I thought so. But the reason it was never implemented was because the idea was tabled — pushed into the background of our then development efforts. That's where it stayed. I came up with the idea fairly early on in the development life cycle. There wasn't a huge code-base to contend with yet, and so less chance of causing problems by introducing a new feature. But all that changed — as the code base grew and the feature set ballooned, my notification idea collected dust. It grew old, frail, and obsolete. Eventually it died.

The concept of idea generation and what ultimately becomes of them applies to a variety of contexts, not just software development. From a vary early age, we're constantly generating ideas, and tabling them. Something that seemed like a good idea an hour ago gets permanently lost. But for that hour, the idea may have occupied the vast majority of your working memory. Until something kicks it out, and the idea generation process is free to start over. It's less clear how this all works on an individual scale, because it's hard to observe unless you've really thought about your own past behavior. But on a group scale where we're collaborating individuals, this suddenly becomes more interesting and tangible. Especially when that group of individuals forms a team with the goal of producing something. The team has a goal, and along the way, a multitude of ideas are generated and tabled. Which ones make it off of the table, and which suffer the fate of my notification idea?

Tabling, postponing, delaying — these all stem from two sources. Either we don't understand what we're doing as part of the bigger picture, or we've got priority contention to resolve. If we're working as part of a team to construct a software product, we must have an end goal in mind. That goal may be clear, somewhat clear, confusing, or somewhere in between. The clearer an end goal is to a team, the less likely they'll deviate and start discussing ideas that aren't relevant. The less clear the goal is, the more effort required by the team to come up with ideas to help make sense of the problem at hand. And as we become more aware of the problem we're trying to solve, and how we're going to set about doing it, the more likely that we'll generate a batch of ideas that get tabled and forgotten over time. That being said, is there really such thing as a good idea being tabled and forgotten about? Was my notification idea in conflict of the project priorities, or did I just not understand that customers had other ways to do what I was thinking about?

When a project team begins to habitually table ideas, on a weekly basis say, it could be a sign of distraction. Contrast this with a focused development effort — one where we're only considering the ideas that help us reach the ultimate end goal. The trouble is that we don't know this is happening until it does. You can't say "OK, team, we're not going to get distracted by ideas that get tabled and never looked at again". This discourages some level of creativity in the collective mindset. You can, however, use idea generation as a vehicle to turn the discussion back toward the appropriate project path. For example, for every idea that comes up — have an asterisk that asks where this idea fits into the context. But have this question ready from the get-go. There will no doubt exist a simple, generic question that tests the feasibility of an idea that can be applied generically. If you cannot come up with this all important question about feasibility, ideas being tabled could be a good method of devising this question.

Tabling ideas isn't a negative trait of software development, or any team setting for that matter. Giving ideas some time to sit idle could prove beneficial. Its like when you're writing code and you're stuck on a painful issue that just refuses to reveal itself. Your best chance of solving it is to walk away, let it sit for a while and come back to it. You table the issue for a bit. Something happens during this time. Your brain is able to make the appropriate connections after focusing on another metal task for a bit. When ideas that get tabled, this gives them an opportunity to reveal how feasible they are. Tabled does not equal forgotten. You record the idea in one form or another, and when revisited, it has suddenly taken on some new properties. Stuff has happened during this idle time — other development activities. Changes to the API, shifts in priorities. These things shed new light on an idea, but they typically only happen when it is sitting in a dark corner, out of the team's view. When we come back to idea that turned out to be a bad one, knowledge should be captured. That is, don't take a bad idea off the table and toss it without examining why it doesn't make sense. What properties about this idea make it a bad one and how can we apply these rules to new ideas that come up in the future?

Tables only have a finite amount of space. You cannot simply pile on ideas that don't deserve immediate attention or aren't going to be implemented at the moment. How does one monitor such a stockpile of ideas? As the idea cache grows, the harder it becomes to manage. Active monitoring of the idea queue is a necessary task if we're to table them at all. Its best to establish an explicit process for performing idea monitoring and evaluation. It them becomes predictable, a reliable way to utilize ideas that may or may not add value to the project. One the one hand, you may have a key feature just sitting there, waiting to be implemented — assuming it hasn't grown old and frail. On the other hand, you may have some ideas that just don't work — and these can teach us something about the nature of our project and development style. One thing to keep in mind when monitoring an idea queue is that stakeholder feedback is an essential tool. Take these appraisals and apply them vigorously to any ideas you have lined up — you'll thank yourself.