let me explain
You’ve bought computer after computer for the past decade. Every year or so, the banners at the computer stores tell you that this is the “latest and greatest”, and that it’ll knock the socks of off anything you own already.
Yet when you bring it home, it still takes a billion years to load up Word. Firefox is still slow. And even something as simple as browsing your computer using the Finder or Windows Explorer is painful. Sound familiar?
As a computer engineer, I’ll tell you that the blame lays entirely on programmers (bias may play in here). Computer processors these days are as fast as they’ve ever been, and they’ve been getting faster every year. Moore’s Law prevails, and that means more processing power available for all the programmers and software engineers of the world. And yet, they seem able to waste all that we’ve given them. Why? How?
it’s not just their fault
It’s you, as the consumer, that’s to blame as well. Consumers love those “Hundreds of new features” stickers, and love them even more if they’re plastered over the next piece of software that they buy. Whereas Word 97 might have been more than you ever needed for word processing, you just have to have the new version of Word with those crazy weird menus on the top. Never mind that you never use it, and probably don’t know half the “new features”.
What I’m driving at is a very clear phenomenon: feature bloat. Engineers love to create new features, and consumers love to buy them. Left in the wake are all the new cycles that the hardware engineers painstakingly provided (we can only bend the laws of physics by so much!). More features mean more code, and more code means more cycles burned. You wonder why your new computer is so slow? Try disabling half the “features” in Windows (Office, I’m looking in your direction).
Even worse than feature bloat is code rot. Code gets “old” after time as different parts of it get updated and others are left behind. Often the oldest, most deprecated code is the most crucial code of the entire project. The code gets written and becomes such an important part of the software that it just can’t be touched, or else everything else might break. So the code just stagnates, using deprecated libraries that are not optimized for new architectures, and the program just can’t get any faster, because everybody refuses to touch the most important part of the code. It’s the pure inertia behind the code that keeps it from changing.
but that’s not half the story
As bad as feature and software bloat is, I don’t believe it holds a candle to a disturbing trend: the rise of very high-level “scripting” languages. Heard of Perl? Ruby? Python? Java?
“Wait a moment,” the programmers are saying right now, “those are a cornerstone of modern programming practice. Without languages like that, we wouldn’t be able to provide anything in a reasonable amount of time.” They might also argue that applications are getting too complex to code in a low-level langauge like C. With the gains in processor speeds, why waste time optimizing every bit of code written?
The short answer is that every cycle counts. No, you don’t need to optimize every instruction. But, especially in a large project, every portion of the code should have at least one person accountable for it. We need to stop code rot. We need to stop using very high-level languages for speed-critical portions of code, and actually invest the effort to understand the best possible way of coding it. Hardware designers won’t be able to keep increasing speeds forever, and eventually software is going to have to do its part and start being clever. And consumers, you need to be able to understand when to say “no” to software. Yes, consumers as a whole will always be swayed by fancy graphics and feature lists, but as an individual take the time to learn the capabilities of the software that you already have. Chances are, it’s able to do everything that you need it to do.