Server-side Upgrades

Every so often, Apple issues a new release of its operating system. Often, these upgrades break various applications and OSX developers are forced to fix issues and release new versions of their products.

Although this backwards incompatible policy causes short term pain for developers on their platform, Apple made this conscious decision because in the long-term it leads to an overall healthier ecosystem. We only have to look at Microsoft's third-party ecosystem to see the alternative.

However, when it comes server-side software, we're wading through the same quagmire Microsoft is dealing with. There is little business incentive to upgrade server-side software and, on the surface of it, a fair amount of pain involved. Thus developers languish with ancient versions of Ruby and Rails, to give one example, dealing with bugs and poor APIs that have long since been fixed.

The majority of mature companies in San Francisco seem to have this problem, with bloated, messy codebases running on ancient versions of Ruby and Rails.  Features that would take hours to implement, now take days, and it's slowly making developer's lives hell.

But it doesn't have to be this way.

We should treat server-side software the same as client side software, and do incremental updates of our frameworks and languages - never more than one version behind. We should dedicate 20% of our time to upgrading and refactoring. Sure, they'll be pain involved, but innovation stagnation due to old and tired software is far more detrimental than the short-term pain of upgrading.