Being in the software tools and libraries business is a funny thing. There aren’t too many of us in comparison to application software creators and so people’s expectations about our products are colored by their experiences with applications.
For most of the software industry’s history, upgrades were a good thing. They added new, necessary features, they added support for the latest operating systems and networks and they added updated glitzy interfaces that excited the user. Today, as the software industry has matured, glitz and support for the latest environmental upgrades is important but many changes are a distraction. The radical interface change from Office 2003 to Office 2007 comes to mind. When one of our salespeople upgraded to a new laptop with Office 2007, he was so upset he could barely work because the interface had changed so much. I’m sure many other companies resisted the upgrade for years because the interface change made the transition so painful to the majority of the users.
With tools and libraries, the issue is even more extreme. Our goal is to work smoothly and invisibly. If we change what the product does, our customers will have issues and their users may be distracted or disabled by changes that don’t help them. If we change the API of the tools (which may be invisible to the application user), many person-years of application code may need to be re-written to simply work as before.
Additionally, many companies mandate that all major version upgrades of application software or its components must be thoroughly tested before deployment, which can mean a test cycle of one to three months or even more. Whether there are any API changes or other visible changes or not in the upgraded software, a test cycle must be run. That’s one of the reasons that we often avoid major upgrades and simply put needed features in our product updates, issued every two months or quarterly.
The scenario above explains why when we announce an upgrade or update; we typically get a reaction and a request for an update from only a subset of our customers. Those who need it respond, those who don’t ignore it for as long as possible. This can be very frustrating for us when we’ve worked so hard to get these new features developed, tested and released.
So how do we keep your customers happy? By updating our products regularly, but “upgrading” rarely, and never changing the API or the product’s behavior. We have some customers who haven’t updated or upgraded in years – because the product works as needed and always has.
So how do we decide when to upgrade? Well, marketing tells us. At some point, the marketing group says you need to show the world you’re investing in your products to make them appreciate the maintenance dollars they’re paying. I already hear engineering groaning and management smiling.