« February 2008 | Main | April 2008 »
March 23, 2008
Software Design: Quality vs. Performance
Last week I taught a course on software design--meaning low-level architectural design, not user-visible design.In the course we talk about various ways to design your software so that it is easier to develop, easier to maintain, easier to test, and so on. The basic rule is to encapsulate variation, meaning to hide things that are different behind a common programming facade so you can treat them as the same. If you look at, say, the way a networking stack is built, your network transport uses an encapsulation that treats all network card drivers the same, and then the network redirector uses an encapsulation that treats all transports the same, and then the rest of the system uses an encapsulation that treats all file systems (which is what the redirector exposes itself as at the top) the same. If you burrow into the details of any of these components, they are using various encapsulations to treat timers and user data buffers and configuration settings and all that the same.
This is all fine and dandy and if you can come up with a design that nicely encapsulates your variation, you will have a piece of software that you can explain to someone else AND feel proud while doing it.
Then performance rears its ugly head.
It's not that performance is a bad aspect of design; in fact it's really the only aspect of your internal design that a user will notice. The problem is that performance directly contradicts ALL of the other criteria that make software "good". Software that is nicely encapsulated simply runs slower than software that breaks encapsulation. If you start out with a clean design and then make it run faster, then the result will be harder to develop, harder to maintain, harder to test, and harder to explain to someone else. It will be "worse" by any measure you can think of--except for speed. Now, speed used to be about the only metric we had for measuring software quality--but the industry has matured a bit. People program in C# instead of C, acknowledging that the result will run slower, but that all the other benefits are worth the tradeoff.
So that is the basic tension in software design: performance vs. everything else. Experience in software design is not so much about knowing design patterns and all that jazz; it's about knowing when to break your encapsulation to make it run faster, and when not to do that.
You would think, perhaps, that cleaner design would run faster. It seems like that should be the case--but it never is. This is one of the reasons that people rail against the perils of premature optimization. The nominal reason is that spending time optimizing early is wasted if the thing you are optimizing doesn't wind up as a performance bottleneck; but I think underlying that is the realization, conscious or unconscious, that optimization means making the code worse, so you should avoid it until you have evidence it is necessary. Of course many programmers think optimization is "cool", both on general principle, and because people can see the results; conversely they don't give two figs for any other aspect of code quality...you can guess the result.
Posted by AdamBa at 07:24 PM | Comments (2) | TrackBack
March 16, 2008
The Agility of Las Vegas
One of the things I love about flying in an airplane is being able to look down at the earth from above; I enjoy both picking out natural features and observing the impact of humanity. When I fly I try to get a window seat and I spent the descent glued to the window, even if I don't know the area I'm landing in.One of the coolest things that's out there on the Internet is the availability of free geocoded satellite images, so you can simulate this experience anywhere in the world. I was in Las Vegas last weekend (for a hockey tournament, not MIX) and while I enjoy the view of the Strip from above, my favorite is sections like this, to the west of the Strip where people actually live (yes, people do live in Las Vegas):
(I did this in Google because I couldn't get Live to give me a link; even with Google I had to hack up the URL it generated). One thing this view demonstrates is the complete artificiality of Las Vegas. When you look at Seattle from above you can imagine that some of the trees were there 200 years ago, and perhaps some of the lakes and rivers are close to their old boundaries; that road you see crossing between those hills might follow an ancient trail. But with Las Vegas, the mix of neatly arranged subdivisions and scrubby desert, with straight roads the peter into nothingness the instant they pass the last house, makes it clear that it's all fake; every blade of grass or piece of gravel comes from somewhere else.
I don't find this appalling at all; in fact I like Las Vegas a lot, both as a real place and an idea. The central notion of Las Vegas is that nothing is permanent, that the present places no limits on the future: what is is just another factor to consider when planning what will be. If there's already a casino on a spot where you want to build your casino, don't worry about it too much. All it means is that the cost and time of your project has to include knocking down the existing casino.
I think this is a valuable lesson for software developers. It's the same thing that YAGNI is about, trying to get developers to be more agile. Too often we get hung up on the way our code is written when considering how to extend it; or we try to plan for the future in our initial design and wind up getting boxed in because we don't want to undo what we did once we figure out what we really needed. Las Vegas doesn't think like that. If a road has to go a certain distance to reach some houses, then you stop the road at that point; if in the future somebody needs to extend the road to reach some new houses, they can build it then (I'm ignoring the foresightful but anomalous planning of I-215 in this argument). Bellagio builds a monorail to the Monte Carlo, then has to trash it to build their new tower 5 years later. Could they have anticipated this? Possibly, but why bother; it's just something else to factor in when the time come. Microsoft is considering something similar, tearing down the ten-year-old Building 24 to make way for larger buildings. At first I found this "wrong" in a fundamental way: "We just built the thing, how can we consider tearing it down?" But if we need the space we need the space, and it shouldn't really matter if the building that is there was built last week or last century. That's Vegas-style thinking, which is what I like about Vegas: it's an agile town.
Posted by AdamBa at 09:12 PM | Comments (3) | TrackBack
March 03, 2008
Is MSFTextrememakeover About to Tip?
I usually only read the blog MSFTextrememakeover when Mini-Microsoft links to it, but lately it is showing signs of creating its own community independent from Mini. If you consider my idea of blog stages (toot, toot) the blog is currently in "storming" mode, but shows signs of moving to "norming", at which point becoming "performing" is just a matter of time.For example, in February the site generated 60 user comments, or almost two a day, which is pretty good. It's roughly where Mini-Microsoft was in about March of 2005; by June 2005, riding a wave of froth whipped up by annual review season, Mini had started down the road to phenomenon-hood. It's true that it's taken MSFTem a year longer to reach that stage than Mini, but the trend is upward.
MSFTextrememakeover has an angle and some expertise (in analyzing financial results) and has lately moved into more general criticism of Microsoft. The author is also starting to adopt a more entertaining style, while maintaining a pretty steady negative attitude--what you might expect if Eeyore could break down a Form 10-K. Mini-Microsoft occasionally offers a glimmer of hope that Microsoft's future is not nasty, brutish, and short, but MSFTextrememakeover generally dispenses with that, which is a useful trait for a blog in the storming phase (if the blog becomes more popular, I predict it will soften a bit).
It occurs to me that there hasn't been much speculation about his/her identity. I sort-of assume he/she worked at Microsoft, but looking back over the posts I would suspect no, although they obviously are a shareholder and likely live in the Seattle area. If they don't work at Microsoft I suppose there isn't even any opportunity for a debate on the morals of what they blog about, but I will point out this article about Wal-Mart bloggers who are free, apparently with corporate blessing, to say whatever they want about the company on a corporate blog called Check Out ("Where the lanes are [gak] all open"). There are about 10 authors on the blog, covering gadgets, gaming, movies and other topics that appeal to people who get their news from blogs (plus Lawn & Garden, not sure what that is doing there). One blogger, Rand Waddoups, writes about sustainability, which is interesting because Wal-Mart is making a big bet on that. A quick glance at reveals few negative comments about anybody; Elmo, Playstation, Verizon, Danactive...they're all good. The most risque item there is a commentary about the upcoming U.S. tax rebate--written by Alex Cook, who also wrote the dubious comments about Vista (is he a Microsoft shareholder?). Still, I like the experiment; Wal-Mart at first tried the PR-driven shiny happy blog, but has now decided that this is the better way to go.
Posted by AdamBa at 09:20 PM | Comments (1) | TrackBack
