Tracking what we forget
Some time ago my fellow programmers and I agreed upon a way to rate the difficulty of a project or task. We called it the elephant rating. The more elephants, the harder it is. Loosely translated, elephant rating refers to the time it will take to accomplish something.
The thing is, we rarely actually use our elephant rating system. Every project or task that is defined and tracked1 but we don’t really use the rating system. The fact that we don’t use the difficulty rating radio buttons is only a symptom of the problem.
The problem is we don’t document what we’ll need to know later. We don’t talk enough about what we’ll need to know to know what we should document. However, as I was writing this it occurred to me that there is record of comment histories, timestamps, and check-ins. Maybe it would be easier to look backwards, asking questions after the fact, after that history can be reviewed.
We are going to forget why we did something or used something we shouldn’t. Or we’re going to create something we shouldn’t. The “shouldn’t” allows for a form of unchecked growth that erodes our ability to understand all that we’re creating.
There are all kinds of other consequences to not understanding what you’ve supposedly created. Like troubleshooting. Something isn’t doing what is expected and you need to figure it out why. But you don’t know the plumbing, wiring, architecture, venting, object structure, or programmatic infrastructure well enough to imagine the functional flow necessary to find the root cause.
That’s when I really wish we’d written something down about what should be happening.
------------------------------------------------------------------------ We use Trac. If you’re a nerd you’ll appreciate this play on words … bazinga! [↩]