Update: this blog is no longer active. For new posts and RSS subscriptions, please go to http://saintgimp.org.
I’m beginning a process of changing a whole lot of stuff in my project at work, so it’s probably a good idea to take a moment to ponder the hazards of that strategy.
I was with my previous group, Microsoft Game Studios, for nine years, and in that time we went through several reorgs that took us through an entire pendulum swing from many small, self-contained studios with lots of duplication and redundancies in resources, to a few large, consolidated studios where almost all resources were shared, and then back towards many self-contained studios. Everything old is new again.
There was a thread on an internal alias recently where people were pondering Microsoft’s naming strategy for its OSes. We’ve had numbers (3.0, 3.1, 3.11), mixed with letters (NT, ME, XP), mixed with years (95, 98, 2000, 2008), mixed with words (Vista), and now we’re going back to just plain old numbers again with Windows 7. Around and around it goes.
There are many other examples from fashion, politics, you name it. I think there are a couple of reasons for this phenomenon.
The first reason is simple human nature. It’s usually easier to see the flaws of whatever you’ve got at the moment and the strengths of whatever you haven’t got. Mmmm, boy, the grass over there sure looks a lot greener, doesn’t it? So we keep chasing “something better” and somehow we never quite catch it.
When there’s only a finite number of options to choose from, the chase inevitably leads you back around to where you started from. Except that usually enough time has passed that the people doing the chasing don’t realize that they’ve just gone in circles.
The second reason is perhaps more cynical; no one ever gets paid to leave things well enough alone. If you’re a senior-level manager, or a marketing strategist, or a fashion designer, or any kind of professional evaluated on the strength of your ideas, then in order to perform well you have to generate and implement new ideas just to stay afloat. Never mind how good the old ideas were. They could have been darn near perfect, but it doesn’t matter. What matters is that you change things around in order to demonstrate that you’re doing something. You can’t march into your annual review meeting and tell your boss, “Well, things have been going great just the way they are, so I decided to leave everything alone and not muck around with it. My major accomplishment this year is that I haven’t broken anything. Can I have a raise?”
Of course, very few ideas are truly perfect just the way they are, and it’s always good to strive for improvement, but this need to justify our existence forces people to make changes whether they’re warranted or not. The bigger the change, the better we look. “Yesterday’s ideas are old and busted; my current plan is the new hotness! And best of all, I won’t have to actually demonstrate the long-term value of my current plan, because next year it’ll be old and busted and we’ll be on to something else!”
Software developers are just a susceptible to these tendencies as anyone else. We just get away with it more often because rather than having a finite number of options that lead us around in circles (and thus expose our folly to those who have long memories), technological progress gives us an infinite supply of brand new ideas to jump on. Though come to think of it, I’ve seen a few old Lisp and Smalltalk greybeards rolling their eyes at the newest whizz-bang features in modern languages, and muttering something that sounds suspiciously like, “Welcome to the 1970s!”
Obviously, there are plenty of times when the status quo really is miserable and change really is necessary. Continuous improvement is a noble and worthwhile goal. But it’s always useful to stop and ask ourselves, “Is this change I’m about to implement really an overall benefit, or am I just chasing myself in circles?”