I’ve been a vocal critic of Android for years. Compared to the glorious polish, consistency, and coherence of Apple’s iOS, Google’s sprawling, inconsistent, and incomplete operating system always felt less. Yes, occasional rays of brilliance, but a sum less of its parts. And to many – although now fewer – extents, I think that’s still true.

But. I’ve come to realize the appeal that lies in figuring out and taming all that sprawl. It invites spelunking in ways that remind me of an earlier age of computing. Hacking consoles, tailoring icon sets, and finding backdoors and alleyways.

It’s a tinkerer’s joy. It’s riddles and puzzles. It’s computing not for the sake of productivity, but as a hobby in its own purpose. It’s the pleasure of making something your own, something unique. A pleasure in part and exactly because it’s not for everyone.

What really got me lured down this path wasn’t just Android in general, though. It was the Moto X in particular. I love this phone. It doesn’t do any specific technical discipline particularly well: The screen is below par (white balance is way too warm), the camera is distinctly mediocre, the battery is so-so. Processor and speed is fine, but nothing wow.

Yet it just feels right in the hand. The last time I recall this feeling was another Motorola phone, the PEBL, back in 2005. It too was nothing special as a technical exercise, but it also just felt great, like the Moto X. Particularly with the wonderful wood back. The 5.2” is perfect. The screen-to-bezel ratio is excellent.

So I keep reaching for the Moto X. Phones have gotten so good that as long as you’re not dependent on things where big leaps are still being made (like the camera), yesteryear’s tech can play second-fiddle to the personal attachment and emotion of the device. That’s a wonderful sign of progress and invitation to diversity.

Anyway, the appeal of the Moto X has sucked me deeper into that sprawling Android land. No, I haven’t given up on iOS. I need to double-carry anyway to deal with two sim cards. But I really appreciate Android culture as distinctly different. Worse in so many obvious ways, and probably for most people, but also alluring and appealing in many other subtle ways.

Some times worse and flawed are just different angles of affection.

The progress of technology needs a full spectrum of adoption to work well. From early adopters who jump in before kinks and warts have been banished, to a late majority who bring scale to the now-safe choice.

If we didn’t have any early adopters ironing out the kinks, there’d never be a now-safe choice for the late majority. And if everyone always jumped on the latest thing on day one, society would waste needless cycles churning through the broken glass of beta software.

But usually people see things a little narrower. They’ve picked a group to belong to, and along with it the story that serves it just. I find that a constant and fascinating example of how we’ll all tell ourselves what we need to hear to feel good about our choices.

In most cases, for example, I like to be an early adopter. Take getting the first version of the Macbook Air, while many fretted about and scorned it for too few ports or not enough speed. I accepted the shortcomings by telling myself that this is ultimately The Future, and I want to be among the pioneers that drags us there, even if it’s a bumpy ride across the frontier.

Further, that if everyone wanted to wait until all the bugs were squashed, the bugs would never be found in the first place, and thus never squashed. See, isn’t that a lovely altruistic cover story for what could just as well be labeled as technological ADD, and just wanting the latest thing BECAUSE?

Same deal works on the other end. There are all these great stories available about how you’re being prudent by waiting to take the plunge on a new product, such that you don’t waste money or resources before the inevitable version 2 or 3. A story filled with the virtue of restraint: An ability to resist the draw of SHINY NEW THINGS.

What’s great is that all these stories can be true at the same time, even if they’re individually in conflict. I can even feel good about a chosen story for my current choice, and then swap to the opposite story for my next choice. Self-deception is grand.

In the early days of Rails, a common dismissal of the framework and its Ruby roots were that these were just toys. Something for kids or amateurs to play with; to build a quick throw-away prototype or system of no consequence. It was most certainly not a tool for professionals building real systems for enterprise, king, or country.

Explicit in this charge against Rails and Ruby laid a grander, sweeping dismissal of toys of all kinds. And more specifically, a rejection of fun and enjoyment as valid reasons for adoption of technology that remains prevalent to this day.

The implication that real professionals do not bother with such childish indulgences. Making Serious Business Software is meant to be a chore. Something to be endured, not relished. An activity worthy of a stiff upper lip, not a smirk.

This charge against childish affection for unserious toys is often expanded to all sorts of wonder, and in particularly magic. In some circles, magic is now downright a dirty word. A label to be applied to anything appealing to greater aspirations than the khaki slacks efficiency of all that oh-so-serious Real Business Software.

But take a step back. Why on earth would we want to associate such joyful memories of learning about the world and its mysteries through toys and magic with that which is beneath us? Even though our goal may well be Serious, why must our approach? Since when is fun, novelty, and exploring the unknown at odds with productivity or value?

A phrase that’s been bothering me for a long time ties all this together: “Use the best tool for the job”. It implies that there is an objective, “best” tool for any programming job. And it leads the search towards those beige horizons of key-point comparisons and feature charts. This does X, Y, Z, thus it must be better than that which only does X and Y. It allows no room for simply preferring A to B on the account that it’s more fun!

Today Ruby and Rails are rarely accused outright of being toys. After more than a decade with roaring, overwhelming success creating an endless stream of “Yup, That’s Serious” business applications, the charge is now obviously preposterous.

But the same charges are still constantly brought against many things new, and as a favorite euphemism for toy goes, “unproven”. If there’s any sense of wonder or unexplained advantage, it readily gets that scornful label of “magic”.

It’s the lingua franca of the incumbents. The manifestations of a rigid minds trying so hard to appear above that childish sense of wonder.

The bottomline: Waging war on toys, magic, and wonder is simply a poor frame of reference. Many of us got into programming exactly because it seemed like magic, like playing with toys. Constructing intricate worlds out of nothing. Legos of logic and rabbit holes of learning.

Love thy toys; love thy magic.

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.

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.