I was thinking about how software based systems tend to develop over their lifetime, and have come to the sad realization that most developers and systems managers are the digital equivalent of pack-rats.

While many are wizards at adding and extending the features and capabilities of the systems they work with (and in some pretty amazing ways), they can be almost dysfunctional when it really comes to getting rid of code and infrastructure that has outlived its original purpose. Some of the best developed systems around seem to just collect screens, functionality, subsystems, API calls, database tables, etc that – while possibly important a one time – add almost no value to the end user today. That fact that the most significant feature of Apple’s newly released “Snow Leopard” version of their operating system is it’s cleaned up, slimmed down code base speaks volumes about the state of complex code packages these days.

There are lots of reasons systems get fat. Some of it comes from engineers simply over-engineering things and making things more complicated than they really need to be – usually by choosing purity over practicality. A LOT more of it comes from the “need” for companies to continue adding new features to their platforms – no matter how marginal – to generate upgrade revenue and justify support contract costs.

Some of it also comes from designers that like to keep the product fresh, programmers that want to add ‘cool new things’ they are interested in, and sale folks that push for one-off additions to try and win new sales.

When it comes to bloat, there’s plenty of blame to go around.

But wherever it comes from, all of this extra code (and the infrastructure that goes into supporting it) typically ends up surviving release after release. And while there may be someone out there that is actually still using it, support for marginally used functionality comes at a steep price. Some areas impacted by this are:

• Complexity: People are already complaining that many technology based systems and devices are confusing and difficult to use. Years of legacy functionality only adds to this problem.
• Mobility: Feature heavy products don’t translate well to small footprint mobile devices. And mobile is where the money is heading.
• Reliability: The more that is put in to a release, the greater the odds that something will fail. There are bits of code living in any complex system that no one really understands, and changing things around it can cause all type of reliability problems that are difficult to diagnose and fix. That’s why there are so many “work-arounds” out there.
• Cost: It costs a lot to add new code (especially when it isn’t really needed by the marketplace). If you also add in the even larger costs needed to maintain it, code around it, and QA it over the life of the product, the ROI starts looking pretty sad.
• Performance: Bloated systems run slower and take longer to load than optimized systems. And sorry – no system is going to get faster by adding more code to it.

This boils down to one simple thing: the need to a more disciplined approach to designing systems. Designers need to place the same value to pruning marginal features from a release that they do adding new ones to it. They need to know their clients, know their markets, and have the guts to make the near term tough calls that will result in a better product for everyone over time.