Programmers love organization. Programming is organization after all, organize electrons in a particular way and some result follows.
Organization is an essential part of programming. Everyone may have their style of organization — just mention a style on your favorite social media to cue up a firestorm of why you’re right and wrong — but few would argue that organization itself is bad.
But why? What are you trying to achieve when you organize something? Most of the time the goal of organizing is to achieve a state of simplicity in which the next step is obvious. The problem is that once you start organizing things there’s a tendency to overdo it. More organization options do not always mean greater simplicity.
Think of your issues and the todo list that grows out of them as a giant pile of Lego. If you wanted to organize a thousand Lego pieces you might choose something like color. That would give you perhaps a dozen buckets to separate your Lego pieces into. That would help you find what you need when you need it. What you don’t want is 1000 buckets each with one Lego in them. That doesn’t simplify anything. Of course, this is exaggerated for effect, but it clearly illustrates that there is a point where additional buckets become counterproductive. The trick is in finding where that point is ahead of time.
A little bit of metadata is incredibly powerful, without it we’d be starting over from scratch all the time. Your project needs some metadata — which elements of metadata are essential will depend on the project — but too much will quickly have the opposite effect. More fields and meta data only bring additional organization if your team is big enough to both value the additional organization and stay on top of it.
For example, categorizing 20 things into 20 categories creates more chaos than it removes, but categorizing those same 20 items into 4 categories can help you find what you need when you need it.
If you have a small team, trying to keep up with too much extra, ever-changing meta data will only bring chaos, not organization. You never want your meta data fields to outgrow your team’s ability to maintain their accuracy. In other words, you just enough meta data is the best goal.
What’s really important to your project? Due date? Version number? Priority? Severity? Estimate? Level of effort? Category? Tags? How do you bring just the right amount of structure and organization?
The problem is that too many ways of organizing, cross-filing and slicing meta data creates more chaos for most small teams. Too many buckets makes it harder to find the Lego you need. Worse, complex organization systems have a way of becoming the focus. What you think will help you keep every idea at your fingertips ends up becoming so complicated its the only idea you can focus on. You lose the bug fixing forest in the proverbial trees of metadata. In other words spend too much of your time filing your work into buckets and you’ll have less time to actually do the work.
Here’s the truth of programming that only comes with years of experience: software bugs are inherently messy. They’re unpredictable and often unreproducible. Some are easy to fix and others border on impossible. The process is implicitly chaotic and unorganized.
But we’re programmers and some fundamental level that chaos and unpredictability is simply unacceptable. So we slice and dice metadata about that chaos; we classify it all and spend our time imposing order rather than actually making things.
Some organization is of course needed. Formal testing is about bringing a degree of order to the process, but as software developers, sometimes we want too much order. The results is too much focus on irrelevant details because they bring a semblance of order.
Rocket Ships and Space Shuttles need very detailed organization. Small web application, static web site, or CMS site only need basic levels organization. Trying to track bugs like Boeing or NASA is overkill in these situations. It won’t make your small team more productive and it won’t get your projects completed. It will more than likely do exactly the opposite.