Son #2 was wearing a shirt that was embroidered with “Istanbul!” (my parents bought the shirt for him on one of their vacations). The thread making up the “I” in Istanbul came undone and he was pulling on it, causing the “I” to disappear. We told him to stop because he would start erasing the whole word.
It’s the same in software
One of the software teams I used to manage talked about the danger of “pulling threads”. In any piece of software that’s been around long enough, there are bound to be parts that are just a little bit off. There might be an extra parameter that you shouldn’t need, or there might be some extraneous code somewhere. You might think to yourself, “Well, why don’t I just fix this right now since I’m looking at it?” That’s a good attitude, but sometimes pulling on these “loose threads” will cause the entire module to unravel. Often, you may find that the thread runs through several modules and fixing this will involve touching a bunch of files.
The danger in pulling on threads in your spare time is that you won’t have enough spare time to finish. Inevitably, you’ll have a half-done pile of work that isn’t fit to check in and that doesn’t provide any visible value.
If you want to pull on threads, tie them to features
The best way to pull on threads is to associate them with features. If you can let features drive things, you’ll pull on the threads that matter. You’ll end up with cleaner code that does something new. It’s really hard to justify work that only (potentially) reduces maintenance.
Pre-emptive thread pulling
Sometimes you can prevent future thread pulling with a little thought today. One of the features that people have asked for in my company’s product is the ability to log notes against effort entries. On the surface, this is easy to implement. You just add a notes field to an applied effort entry and there you go. However, I’ve been hesitant to do this because I know this would create a thread that would have to be pulled at some point.
How do I know this? It’s because I know the data architecture of Frontier, and I know this isn’t the right way to solve this problem here. The right way involves architectural changes. It’s a little more involved, but the result will be something much cleaner and much more powerful. So that’s what I’ve spent the past week doing–pulling this thread before it exists.
Don’t do too much pre-emptive thread pulling
Too much pre-emptive thread pulling, though, leads to overdesigned software. You’ll never get it done. You’ll spend too much time analyzing cases and sub-cases, and inevitably, one of the cases you hadn’t considered will be the one that turns out to be important…and many of the cases you did consider will turn out to be threads that will need to be pulled some day 🙂