I remember watching a TED talk a while back where the speaker described how to represent data from different scales at the same time. The example had a picture of a house superimposed onto a street map superimposed onto a city map superimposed onto a country map, etc. It was hard to see all of this information at once, but occasionally you’d get flashes of how everything fit together.
Software architects have to do this all the time
One of the most important architectural skills is seeing through all of the layers of a piece of software at the same time. I don’t think you can be an effective architect without this. An architect has to know how a change in one layer will affect all the layers in a system. Often, something that makes sense in one layer is a terrible idea in another.
What makes this even more challenging is that each of these layers may involve different technologies. Not only must an architect have the vision to see potential problems, but they must do so in a way that holds multiple paradigms and structures in place simultaneously while threading multiple paths through all the layers. Occasionally, while doing this, an architect will see everything fall into place and have a momentary, deep insight into the entire system. The challenge then becomes capturing something coherent enough to act on before the insight vanishes.
It requires lots of practice and experience to develop this kind of multi-level vision. I don’t think you can learn how to do this casually—it’s something that you have to work at for a long time. How long? I think the current rule of thumb is for about 10,000 hours.
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 🙂
Sorry I haven’t been able to post lately. I was hoping to get a backlog of posts ready, but my house sold in that period so I had to get everything packed up in Portland, then drive down to San Jose, unpack everything, and then get it put away.
Since I’ve been doing a lot of driving lately, I thought I might comment on the differences between driving in San Jose and Portland. In Portland, the freeways go over lots of hills, especially as you head in to downtown from the West Side. Because of this, you find yourself changing your speed a lot (if you drive stick, you change gears a lot, too). It makes driving a more conscious activity. In the Bay Area, the freeways are pretty flat. I found myself using cruise control for the first time in many years. Also, since the speed limit in the Bay Area tends to be 65 mph instead of the 50 mph in Portland, you don’t have to worry as much about speeding. Also, now that many of the freeways have been widened to at least 4 lanes (in the past 15 years that I’ve been away), traffic seems to flow pretty well.
What this all adds up to is a more reflective driving experience in the Bay Area. Once you have cruise control on, and you have your 2+ car lengths in front, and you have your 4 lanes of straight flat highway in front of you, there isn’t all that much to do but think (particularly if you turn off the radio).
Rino’s Freeway Thoughts
I find that I go through the same set of topics whenever I drive in the Bay Area. I often think about traffic as water flowing through a tube. I wonder if anyone’s tried to model this using the Navier-Stokes equations. I wonder if you can compute a Reynolds number for traffic and what turbulence means.
I’ll look at street signs and remember what I thought about them when I was growing up. I still don’t know if the Tennyson Rd exit was named after the poet or if the Jackson exit was named after the general. The exit for “A street downtown” still brings a chuckle.
After this, I start thinking about things I’m working on. I used to think about homework. Now, I think about how to build my company. Now that I’m starting to get settled in San Jose, I need to start putting some of those thoughts into action! I’ll keep you posted 🙂