Global Moxie

Spinning your wheels trying to keep up with software updates? Photo by J.M. Simpson, The Weekly Volcano.

One of the challenges of software development is settling into a release schedule that is sustainable not only for you but for your customers. You have to update often enough to keep the latest version free of known bugs and to keep your customers happy with a steady diet of feature improvements. (And not least: In the software business, version releases drive revenue and attract new customers.)

On the other hand, you have to beware of upgrade fatigue. Release too often, and customers will tire of the “download, install, rinse, repeat” cycle. The thing that you quickly learn, however, is that one customer’s “too often” is another customer’s “too slow.” The best you can do is try to strike a reasonable, happy medium.

Recently, though, I had to break my usual rhythm, releasing three new updates to Big Medium in a one-week period after the first update (v2.0.4) introduced new bugs that, alas, themselves required immediate fixes. All this update activity prompted a note from Karen Kaiser of Key West Webworks, a longtime Big Medium customer who uses the software to power her elegant designs. Karen let me know that even monthly updates present a business challenge for small design firms. I offered some suggestions about what to expect from Big Medium updates and how she might craft a realistic upgrade schedule for her clients.

I thought the exchange might be of interest to other Big Medium customers, too. With Karen’s permission, here’s the e-mail that she sent:

I so much appreciate your ongoing efforts to continue to upgrade and improve Big Medium. But this recent flurry of updates and fixes causes some business problems for us. It’s hard to charge your client for repeated updates within a short period of time. Clients expect annual software updates, and the fees that go along with that. Perhaps even a six-month cycle of updates would be something we could sell.

But I really just have to eat the time it takes to update web sites with this type of bug-fix flurry. Since I have so many clients using Big Medium, that’s a lot of time that I won’t get paid for.

Frankly, since I could not possibly charge clients for nearly monthly updates, I basically have to try to decide WHEN one of these upgrades is significant enough to implement, and hope that the day after I do it there isn’t another hasty bug fix.

Complicating this, I also need to monitor these progressive improvements so that when a version comes along that does offer significant performance enhancements that my clients really should have, that their version is not so out of date that it requires a complete reinstall or perhaps a series of retro-updates to make it compatible with the next greatest version.

I just wanted to mention this to you. During the beta period we all signed on for this type of continual upgrade, but once a product is released I think it would be more practical to release upgrades on some sort of planned cycle that would be understandable to clients so that the lowly web masters can get paid for the time it takes to keep the software current. :^)

Here’s my response:

Many thanks for your thoughtful note and, as always, for your support of Big Medium. Boutique design outfits like yours are very much my target audience, so I do take very seriously your concerns about how to keep up with a regular flow of updates.

Here’s a bit of background and, for what it’s worth, some suggestions about how you might construct a manageable update regimen.

“Double-point” updates (e.g. v2.0.1, v2.0.2) will continue to keep coming on a regular basis as bugs surface. Although these double-point releases often do include minor new features, their main purpose is to address bugs that have reared their heads. These are typically minor bugs that appear in relatively rare situations, but I think it’s only responsible to address these bugs promptly. I’m not sure that I’d be doing anyone any favors by artificially holding back fixes for a slower release schedule. Ethically, I feel it’s important to get fixes out there in a short timeframe; the pool of known bugs should be drained early and often.

Ethically, I feel it’s important to get fixes out there in a short timeframe; the pool of known bugs should be drained early and often.

My pace for these double-point bug-fix releases is typically once every one or two months. This past week, unfortunately, has been an exception. Two significant regression bugs were introduced in v2.0.4, prompting the fast release of v2.0.5 and v2.0.6. I’m not happy that there were three releases in such fast succession. That’s not the way it should work, and it wasn’t my plan. Unfortunately, these bugs were significant enough to Big Medium’s regular operation that I could not let them stand for another several weeks, or even a few days. Fresh updates were merited.

Ideally, of course, these bugs should have been found and fixed before the 2.0.4 update was even released. I tested that update vigorously for a week before releasing it, and I ran it through my collection of over 80,000 automated tests that check various aspects of the software. Unfortunately, I simply missed these bugs. I hope to do better in the future, and I’m continually improving my test framework.

I’m aware that this could be perceived as being sloppy, but I think it’s more fair to characterize these quick-turnaround fixes as “responsive.” Bugs are an unfortunate fact of software, and the best service I can provide is to get the fixes out as quickly as possible.

You wrote:

Since I could not possibly charge clients for nearly monthly updates, I basically have to try to decide WHEN one of these upgrades is significant enough to implement, and hope that the day after I do it there isn’t another hasty bug fix.

I think you’re exactly right. You have to decide when the upgrades merit the effort. But by getting fixes and minor new features out there regularly, I enable the decision to be in your hands, rather than forcing you to wait according to an artificial release schedule.

So, how to decide when and if to upgrade? I include a detailed list of all of the changes with every version announcement. For the double-point releases, the changes are typically going to be bug fixes and minor feature additions. Generally speaking, this means that if your clients’ sites are working well as-is, an upgrade isn’t strictly necessary. When an update is strongly recommended for all users -- in the case of a severe bug or security fix, for example -- that will be called out clearly in the announcement.

Apart from those cases, you should feel free to upgrade only when there’s a bug fix or feature addition that directly impacts your client sites’ operation. If you have any questions about the details of a new release and whether it applies to your clients, feel free to shoot me a note at support@globalmoxie.com. I’m always happy to field any questions.

If you can’t keep up with these monthly release updates, which is understandable, I recommend that you craft a schedule that is reasonable for you and your clients. Update every six months, for example, making exceptions for the (very rare) appearance of severe bugs or security issues. To avoid the “hasty bug fix” issue that you mention, you can wait a week or two after a double-point update. I obviously do my best to avoid introducing significant new bugs, as happened with the v2.0.4 release, but in the event that it happens, those new bugs should be flushed out within a 14-day timeframe.

You also wrote:

Complicating this, I also need to monitor these progressive improvements so that when a version comes along that does offer significant performance enhancements that my clients really should have, that their version is not so out of date that it requires a complete reinstall or perhaps a series of retro-updates to make it compatible with the next greatest version.

“Single-point” releases (2.1, 2.2) are for significant feature updates and will typically come out just once or twice a year. These releases include major performance and feature enhancements. There will be betas released in advance of these major updates to allow a period of public testing, and there will be plenty of lead time to see them coming.

These single-point releases will indeed typically involve re-uploading all of Big Medium’s files, but please rest assured that these versions, as with all Big Medium 2 updates, will come with an updater script that will handle any behind-the-scenes data changes. They will always be backwards compatible to all other v2 versions of Big Medium.

You might choose to peg your updates to the early double-point releases of these major updates (2.1.1, for example) so that you’re keeping your clients up to date with major feature updates, along with the early set of inevitable bug fixes.

I do apologize if you find the current flow of releases overwhelming, but I hope this background might help you to craft a maintenance schedule that works well for you and your clients.

Hope that helps, and thanks again for your enthusiasm and support!

Tags: bigmedium, business, customerservice, software, work