In the OS arms race, third-party developers must sweat just to keep up

The ever-increasing pace of technology change delivers lots of lovely new gadgets for consumers, but spare a thought for the poor third-party software developer. While Microsoft is already offering sneak previews of Windows 8 and Apple is rolling out yet another major release of OS X, we still have clients running Windows 2000, Windows XP, Windows Vista and Windows 7, and expecting us to support all of them.

We develop budgeting and forecasting software that’s based on Microsoft’s SQL Server, so the picture is even more complicated. We have to maintain versions for SQL Server 2000 (although we’re trying hard to wean our clients off it), 2005, 2005 SP2, 2008, 2008 R2 and soon 2010.

The costs (and risks) of upgrading are high, so we understand why clients want to wring the last cent of value out of their investment in any operating system, but there are costs attached to that strategy too. The problem is that many of those costs are hidden, so people tend to ignore them.

One hidden cost is that of third-party software: it’s more expensive than it needs to be. This isn’t because of any evil plan on the part of software developers — it’s simply that the more versions of Windows and SQL Server we support, the more versions of our own software we have to change every time we upgrade or add a feature. Similarly, we have to review and tailor all our own code every time there’s a new operating system release.

That means we need to maintain a bigger developer team that we’d prefer to. Worst of all, that team spends more time on testing and rewriting old code than on developing new features: So our clients not only end up paying more, they get less value for it.

Basically, third-party software developers are forced into spending far more on code maintenance, which is pure overhead, than on R & D. This opportunity cost is a big deal: with each major release come major new possibilities that we can’t take full advantage of. If we do add new features, we need to write additional code to conceal them from people running older versions.

Sadly, it all adds up to ugly code that’s in frequent need of revisiting.

This problem isn’t unique to my own firm: everyone is grappling with the same challenge, and it’s becoming harder and harder for independent firms to develop serious business systems. Many of these systems fill niches that are too small for the major players to bother with — without them, those customer needs wouldn’t be met at all.

As it is with natural ecosystems, so it is with software: diversity is a source of strength. The more different kinds of software development firms and systems there are, the better for the firms and people who use those systems. Anything that threatens this diversity is a problem that should be taken seriously.