News

The danger of the magpie developer

• By Mike Gunderloy
• May 17, 2004

My wife was venting some frustration to me yesterday afternoon: "The satellite TV is on the blink and the satellite radio loses its signals and my computer slows down mysteriously though that's probably a RAM issue and replication between the SQL Servers is broken again and could you fix it please?" (Yes, we have the sort of high-tech family where my wife is more likely than I to notice that replication to our offsite server has crashed, usually because the flakey rural phone lines have burped again). There wasn't much I could to about most of those problems, but at least I could think a bit about the processes that have gotten us into this mess.

As any software developer knows, it's impossible to just sit down with a spec that says "build the best possible product" without knowing a lot more about what "best" means in the current context. There are many conflicting dimensions that can go into "best", including:

• Functionality
• Flexibility
• Reliability
• Security
• Future-proofing
• Localizability
• Prettiness

And probably lots of others I'm forgetting at the moment, as well. The point is that building a software product inevitably involves tradeoffs among all of these dimensions, as well as the big one: time-to-market. Remember, shipping is a feature! So we can never produce perfect software, we just produce the best software that we can in the time available (or go down with the ship, as many of us did at the end of the dot-com bubble.

Yet it seems to me that developers do not trade off between all of these dimensions evenly. Given a bit of time to throw at the product, and a lack of clear direction of what should be done next, we almost always tend to throw in new features, or, worse yet, eye candy. Something new, whether it be a way to enable run-time logging, or an Office XP menu style control, or an XML output engine, catches our eye, and in it goes. I am reminded of the magpie, which has the reputation of stealing shiny objects that catch its eye and lining its nest with them, even though they have no real purpose.

When I look back over the last decade or so that I've been actively developing on Windows, I'm disturbed by what appears to be a long-range trend: things have gotten more functional and flashier faster than they have gotten more reliable. Or, to put it another way, our magpie instincts have gotten the better of us, and we've shoved in more features in preference to making sure that the existing features work well. This is biting us back now in one particularly critical area: security. The rise of the always-on and always-connected computer, together with the gloabl Internet, led to an unanticipated side effect of security issues suddenly being much more important.

Microsoft assures us, of course, that the next generation of Windows - Longhorn - will take case of all the security stuff and add new functionality and be wonderfully pretty to look at. My own personal (and somewhat cantankerous) opinion is that both the features and the user interface are a bit too unrestrained; I don't personally feel the need to be able to catalog all file metadata centrally, or to have rotating 3D graphs behind translucent buttons on the user interface of my applications. Such things will sell software, though, so I know my cantankerousness will do no good in this regard.

I can't help wondering whether the current focus on fixing security bugs is just the tip of the iceberg, though. What happens when the tidal wave of poorly-implemented and poorly-tested features (not necessarily in operating systems, but in the applications software we layer on top of them) breaks over our heads? What if the whole rickety structure becomes too much for the average computer user to deal with? My own suspicion (or hope) is that we're coming to the end of an era when adding features and flash was the most important thing, and it's now time to consolidate and concentrate on some of those other aspects of producing good applications.

This will require restraining the magpies, of course. But if there are any younger developers out there listening: take some time to get back to the basics. Learn how to build secure and reliable applications that satisfy real business needs. Thee aren't enough people with those skills right now, and you should do well in return.