Would you hire the last Delta representative you spoke with if you owned a customer service company?
First question in the Delta Airlines customer service follow-up survey. Love it.
Would you hire the last Delta representative you spoke with if you owned a customer service company?
Of the many axioms in the world of software, few rise to the occasion of Thou Shall Not Rewrite Your Application. Spolsky called it the “single worst strategic mistake that any software company can make” in his seminal 2000 essay Things You Should Never Do.
The Big Rewrite has been likened to all sorts of terrible things, but perhaps the most damning is its association with declaring technical bankruptcy. Basically, the only time it’s reasonable to embark on the terribleness of the rewrite, is when you’ve been profligate cowboy coder. When your mountain of technical debt is crashing down upon you.
So it’s the white flag, then. It’s giving up. Capitulation! The error of your inadequacy has finally caught up and will be taking you to the cleaners. Who the hell wants to be that sorry sob of a programmer!?
No wonder programmers are loathe to question the wisdom of NEVER REWRITE. Either they’ll reveal their own morally deficient ways, or they’ll be seen as apologists for others traveling that deviant path.
Now, axioms develop for a reason. Many a rewrite has been started and gone astray for all the wrong reasons. Either it truly was a result of technical bankruptcy, or, perhaps even worse, it was a result of perceived technical bankruptcy by a new team uninterested in learning why things became the way they are. As Spolsky quips, such a rewrite is basically the same software with more and different bugs!
But there are other types of rewrites. The one most dear to me is the “Don’t Try To Turn A Chair Into A Table” rewrite. It’s the one we committed when we launched the new version of Basecamp a couple of years ago. A full, start-over, everything-is-reimplemented rewrite of Basecamp because we wanted it to do different things.
Yes, Basecamp Classic and the new Basecamp both juggle many of the same ingredients of project management and collaboration, but they’re mixed together in very different curations. So while we could have gotten from A to B one carefully tested refactoring and commit at the time, it would have been a fool’s errand.
Starting over allowed us to question the fundamentals of how the application worked and how it was implemented. We were able to make leaps, not just skips.
A chair can indeed be turned into a table with enough effort. Both have four legs, and all you need to do is chop off the back of the chair, and somehow refasten it to the base to extend the surface. Oh, and maybe some new wood to raise the legs up higher. It can be done, but why on earth would you?
So we decided to leave the chair alone. People were using the chair, and still are – years after the new table premiered! And we got to build a beautiful new table that’s been serving us so very well for the last couple of years.
That’s really the bottom line here: We rewrote Basecamp from scratch and it turned out great! Better than great, actually. We got to leave well enough alone for people who had adopted and grown accustomed to Basecamp Classic, we got to offer a brand-new product to new customers that was the very best we knew how to make, and we got a greenfield codebase to enjoy as well. Plus-plus, would do again!
So what am I saying here? Rewrite willy nilly whenever you get blue over seeing a few modes of progress made cumbersome because of poor past decisions? Of course not. Embarking on The Big Rewrite is not a choice to be made lightly, but a choice it remains. It should be one of the options on the table.
If you’ve accumulated enough fresh ideas about how your application can be radically different and better, The Big Rewrite may very well be just what the carpenter ordered.
A common approach to problem solving is to consider it binary. Either you’ve fixed the issue or you haven’t. Some problems fit that domain well: Either the calculator returns 2 on 1 + 1 or it doesn’t. There really isn’t much of a middle ground.
But many problems in product development aren’t like that. They’re far more hazy. Solving a problem in 100% of the cases for 100% of the people might very well not even be possible. So thinking of such problems as binary flips is not only futile, but harmful.
A better way to think of hazy problems, like “how easy is it to get started with Basecamp?” or “is the query interface for Active Record as readable as can be?”, is to focus on mere progress instead: Are we making it better?
That’s such a disarming question to pose of new initiatives. No longer does an idea have to contend with being The Solution, it simply has to contend with making things better.
It makes it so much easier to find consensus that way. Everyone sits with their own idea of The Solution, but most people can agree whether A is better than B, when both of those states are real.
Compare the concrete, make it better.
Almost ten years to the day, we launched a free service called Ta-da List: A simple way to manage and share to-do lists online. It’s funny to read the announcement now. You need a MINIMUM of Internet Explorer 6 to run it! Ha.
Well, we retired Ta-da List in May, 2012, as it had run its course, and we weren’t looking to update it to keep pace with progress. But what we didn’t do, was to kick off everyone who was happy to use what they had. Ta-da List is part of our legacy, and the courteous thing to do is to respect your legacy.
If you have a Leica M3 – a camera produced between 1954 and 1967 – they’ll still fix it for you in Germany. Half a century after they stopped selling it! That’s legacy, and an inspiration.
In 2014, there were just under 5,000 people still happily using Ta-da List to track their todos. That makes me smile. No, it’s not the best to-do tracker in the world. There’s no mobile app. It’s antique software. But it’s our legacy, and it feels good to be there and be dependable for the users who are happy with what they got.
When we Became Basecamp that was a theme we talked about a lot. The internal phrase is that we want to produce software that’s around #UntilTheEndOfTheInternet. So much software and so many services these days are unreasonably flaky and undependable. Not in the sense that they crash (well, that too), but that they simply disappear from one day to the next because of whimsy, acquisition, or worse.
I don’t want to be a digital landlord that evicts people who placed their trust and their data with us, just because “our priorities have changed”. At the same time, we also don’t want to continue selling or offering antiques to new customers. This is the compromise: No new users, but the ones we got we’ll take care of forever.
So cheers to Ta-da List and the 5,000 people still using it. We’re glad you’re still here, reminding us of who we are and where we came from.
There’s an exhilarating freedom and motivation in having nothing to lose. History is full of amazing tales of underdog ingenuity. Likewise, stereotypes abound of the mighty falling flat, trying desperately to protect what they’ve got.
But even more insidious than actively trying to protect what you have, is frequent fretting about how to do so in your mind. It’s so easy to fall into an endless churn of worries about how your precious gains could vanish tomorrow.
This is known as loss aversion. It’s the default routing of our evolutionary brains, and it can lead to unnecessary stress, lost opportunities, and poor decision-making. But it doesn’t have to be your destiny – it is indeed possible to reroute.
The stoic practice of negative visualization is one way to do this. If you imagine, clearly and frequently, the worst case scenario, you can work on coming to terms with its consequences. Usually they’re far less dire than your worries would lead you to believe.
I’ve employed this technique from the get-go with everything I hold dear in my life. As an example, here’s how I’ve applied this to the thought that a terrible end could prematurely doom Basecamp.
It’s easy to contemplate all sorts of spectacular ways this could happen: A massive hack that destroys all data, all backups. Some sort of epic fraud that indicts the entire company. I let my mind seek out all sorts of terrible corners.
Then I consider what’s left: I got to work with amazing people for over a decade. I grew as a programmer, as a manager, and as a business person immensely. I enjoyed most days, most of the time. I helped millions of people be more productive doing all sorts of wonderful things.
I’m so much better off for having been through this, regardless of how a possible end might occur for the company. This makes whether circumstances allow us to continue for another decade (or five!) a lesser deal than the fact that we did for one.
This brings a calmness, a tranquility as the stoics would say, that’s incredibly liberating. A head free of fear or dread. I believe this not only is a saner, healthier way to live (stress wrecks havoc on the body and soul), but also better for the company.
We’re not running Intel, and I don’t want to have Grove’s “only the paranoid survive” as my modus operandi. I want to retain the underdog sense of having nothing to lose, even when conventional thought might say I (and the company) have everything to lose.
That’s the tranquil freedom of the stoic way.
Kathy Sierra’s Featuritis Curve helps focus the mind during feature discussions.
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.
Remember the really cool Farecast app that would tell you whether prices for airline tickets go up or down? We featured them back in 2011, after they had been bought in 2008 by Microsoft for $115M. Then, the story from CEO Etzioni was:
So I’m very pleased that Farecast was picked up by Microsoft, was enhanced to become Bing Travel, and is now widely available and broadly used.
I was just tipped to this story from April: Farewell, Farecast: Microsoft kills airfare price predictor, to the dismay of its creator. Not surprisingly, the attitude post-exit of what happened to Etzioni’s idea isn’t quite as bright:
So, we end up with Bing travel as a thin veneer that redirects users to Kayak, while Google innovates with Google.com/flights, which I now use all the time. Google 1, Bing 0.
Getting access to all that money, all those resources, is always the glitter story that surrounds acquisitions. The drab reality is often a lot like the hangover you had after celebrating the check clearing.
Clutter is taking a toll on both morale and productivity. Teresa Amabile of Harvard Business School studied the daily routines of more than 230 people who work on projects that require creativity. As might have been expected, she found that their ability to think creatively fell markedly if their working days were punctuated with meetings. They did far better if left to focus on their projects without interruption for a large chunk of the day, and had to collaborate with no more than one colleague.