The other side of version-less software

The wonders of version-less software as a service are extolled from all corners of the internet: Nothing to install! Updates come to you automatically! Everything just gets better all the time. And that’s all true, but it’s not the whole truth.

The flip-side of this automatic wonder is that you’re forcing constant change on everyone. The only way to prevent that from being unbearably grating is to make it incremental, and exclusively additive.

There’s no room to change your mind about the fundamentals once a sizable customer base has been trained to expect the familiar. Anyone who’s ever tried to remove a feature from internet software will likely be so scarred from the experience that they never attempt it again.

This is where it’s so easy to cry boohoo as a developer: “Oh, those damn users just can’t see or accept the brilliance of newness! If only they would be patient, relearn everything for me and my creations, we’d all be better off!”

The fact is they probably wouldn’t. Most software just isn’t important enough to warrant a steady stream of newness friction. Makers eat and sleep their software all day long, so most changes seem small and inconsequential. But users have other worries and changes to face in their daily lives; learning your latest remix is often not a welcome one. They invested attention to learn the damn thing once, then went on with their merry life. And what’s so wrong with that?

Nothing, I say. We have a very large group of customers who still enjoy Basecamp Classic. It’s been 2.5 years since we released the new version, but the Classic version continues to do the job for them. It just hasn’t been a convenient time for those customers to disrupt their work to upgrade Basecamp, or maybe they just don’t like change. It really doesn’t matter.

That doesn’t mean they’re not happy customers. Just the other day one wrote to say how much they loved Basecamp, yet felt obliged to apologize for not yet upgrading to the latest version. There’s nothing to feel bad about! Except that the software business makes us feel like there is.

Installed software didn’t have this kind of tension because of versions. If you were using Photoshop 3, you weren’t forced to upgrade to Photoshop 4 until you were ready. (Though other network effects, like sharing files sometimes forced the issue, but that’s a separate story). Something important was lost when we moved away from those clear versions.

Users lost the ability to control the disruption of relearning and adjusting to changes; developers lost the will to commit to revolutionary change.

Yes, splitting versions, like we did with Basecamp Classic, isn’t without complication. But from someone who’s been through the experience, the complication is not only overstated, but the benefits have also been under explored.

Maybe it’s time to ask yourself: What could we do if we weren’t afraid of revisiting the fundamentals of our software? What if we just did a new version and kept supporting the old one too? 2.5 years after we committed to this strategy, we remain happy with this rarely chosen path.

Brian Whipple

on 01 Oct 14

Very interesting post. The questions that come to mind are. . . Will you support Basecamp Classic as long as there is demand? Does your team have to put in a significant amount of extra work to support the two applications? Is this sustainable from a business perspective?

I would love to hear your thoughts on this. Hope I don’t come across heartless. I just know that companies have to consider the costs when making decisions like this. If it still works from a business sense, then this might be something we implement for our application.

DHH

on 01 Oct 14

Brian, it’s not free, but maintaining your legacy and taking care of your customers never was. At the moment, there are certainly more than enough customers who still use Classic to make it profitable. But there may well come a day where it’s not strictly profitable, and when that day comes, we’ll eat the cost to do the right thing.

Michael

on 01 Oct 14

I agree with this essay. I would add that you should ask whether your new version is worthy enough to justify the split, though. New and old Basecamp get the some jobs done, but they’re radically different. Then again, one wonders how much better might other subscription web software be if its developers were free to maintain the old version separately.

drawtheweb

on 01 Oct 14

“Anyone who’s ever tried to remove a feature from internet software will likely be so scarred from the experience that they never attempt it again.”

+1 for this

The worst is when it’s a bug (according to your team) that allows some sort of loophole. Users are gladly diving into that loophole and then you release a patch to plug the hole…

Glenn

on 02 Oct 14

“The flip-side of this automatic wonder is that you’re forcing constant change on everyone. “

I use the analogy of a grocery store. I have a particular grocery store that I shop at because I know where everything is, which allows me to to cut my shopping time in half. I like it this way, and I may even overlook some things that I don’t like because of this familiarity. I know when a new manager takes over because he has better ideas of how everything should be displayed, so he rearranges everything. The result is that I have to relearn where everything is. If I have to relearn my favorite store from scratch, why not just move to a new store? My favorite store has lost it’s competitive advantage for me.

This is exactly what happened with Microsoft Windows for me. I was a very happy user of Windows for 25 years. I loved Windows XP, but then was forced to change to Windows 8. Instead of spending my time on productive tasks, I was forced to rewrite my mental habits and start from scratch on a subpar and unfinished operating system. Earlier this year I switched to a Mac, which was less of a change for me than learning Windows 8, and it was a finished, solid operating system. I love my Mac now but I never would have changed without Microsoft believing that forced change is a good thing.

Microsoft constantly changes the appearance of Outlook also, which drives me crazy (yes, I still use Outlook but I will change when I find something better and more consistent).

Paul

on 02 Oct 14

Nice. And too bad the big A probably won’t consider this. CS6 could go on forever on many a computer. But it won’t last with OS changes/updates and patches and support going forward.

Trevor

on 03 Oct 14

@Basecamp

I assume this means your creating v3 of Basecamp and will be selling it as a standalone product.

Jonathan

on 03 Oct 14

Will Basecamp Classic be supported in 5-10 years when it has only a few hundred users and costs more than it brings in?

If you have the margins to support legacy web apps, fine and dandy. For others though, branching and supporting two separate apps might be financially untenable.

Some products compete on price. Some products compete on quality.

I think this is just another point of competition: stability in user experience (e.g. “Will the app solve my problem tomorrow as well as it did today.”)

Some apps will compete on stability. Some will compete on solving new jobs.

What ever happened to taking a strong opinion?

Nils

on 05 Oct 14

I both agree and disagree.

Changing things too freely drives people insane and to your competition for the reasons you’ve mentioned.

But regarding the extreme case: trying to accomodate for each outdated version, usecase or API sends the wrong signal and teaches your users that you will always support even the crappiest and oldest thing they have lying around.

Yes, particularily enterprise is running very old software on very old machines but I argue that this is the sideeffect of not having allocated enough resources in the first place: Your software MUST keep evolving and it MUST react to dependencies evolving. You’re doing it wrong when you demand “write once, never touch again” projects from your staff.

At first, things work fine but after some time you start to not only maintaining your software and its interfaces to its dependencies.

But instead you need to start managing the entire stack all the way down to the outdated operating system and hardware. By then it might be too late to change things or fix problems: Hardware was phased out, migration paths are gone and your users are adjusted to you never changing a thing.

At this point the cost of maintenance explodes.

Not to mention the emotional cost: It is fun to work on new projects or to manage newer generation software. It is an incredible drag to maintain old software that seeminly just a few incompetent bosses are relying on. I argue that people tend to burn out or change jobs more when you have too many loose ends lying around.

This discussion is closed.

About David

Creator of Ruby on Rails, partner at 37signals, best-selling author, public speaker, race-car driver, hobbyist photographer, and family man.