Code bloat abounds

Sales-driven software cycles beg the question of upgrades

Application vendors love to wow customers with bells and whistles packed into each new version of their software. But after a few successive releases, the sheer number of features in an app can start to weigh it down. As "code bloat" sets in, user experience inevitably starts to suffer. It's little wonder why corporate users -- especially those unlikely to alter their application habits -- are growing increasingly reluctant to comply with IT mandates to hit the upgrade button.

To be fair, writing applications is a lot more demanding than it used to be. Developing software that performs effectively in a multithreaded, multitasking environment isn't easy. Neither is juggling all the elements of a windowing GUI. If it weren't for sophisticated frameworks that automate these chores, developers would spend a significant portion of their time reinventing the wheel. Too much reliance on these tools, however, can encourage lazy programming practices and poor design.

In the old days, programmers optimized code by hand, byte by byte. Today it's a different story. Whether they're building software for the desktop or the datacenter, modern application developers rely on huge libraries of third-party code, often with very little understanding of their inner workings.

Modern development environments are different, too. Languages such as Java and C# relieve programmers of the burden of housekeeping tasks, including memory management and security, but they further conceal the internals of the system behind layers of abstraction. It's hard to optimize code when you don't know what's going on at the lowest levels; no wonder so much software seems sluggish and cumbersome.

But developers shouldn't shoulder all of the blame for bloated upgrades that perform more slowly than their predecessors. After all, when software development cycles are driven more by sales than by sound engineering, it only makes sense to expect the worst. Rushing a product to market to meet a published ship date is a recipe for disaster, yet it happens so often that customers actually expect it. Massive bug fixes, service patches, and suboptimal out-of-the-box performance have become a way of life.

Will high-quality software ever become the norm? In part, that's up to us. As customers, it's time we voted with our wallets. So long as we're willing to skimp on code quality for the sake of the latest, up-to-the-minute upgrade, software vendors have little incentive to ship us anything but second-best.