jemery.com

tl;dr: Fix bugs quickly, write features and core slowly, use github. Or just scroll through the graphs.

We’re either at, or past, my 30 year anniversary (I was a kid, can’t remember okay?) of either using, writing or managing software. I have over those years, developed some impressions and, ahem, opinions. What follows is a framework for thinking about a piece of software’s awesomeness.

For the purposes of this post we’re going to define “awesomeness” as a very general sense of “useful quality,” meaning a qualitative appraisal of the overall balance of usability, utility, and bugginess. This is inherently a qualitative analysis, but I’m making extensive use of graphs for the purpose of providing a framework for visualizing and thinking about where a particular piece of software sits on the Awesomeness Curve.

So, what does the Awesomeness Curve look like?

Essentially, we have the green area, which is early (or beta) software that is interesting and gaining users who are most likely early adopters and more likely to be adept at finding and utilizing working arounds for bugs or missing features.

The blue area represents software which has enough features to make it really useful, has few enough bugs to not make you want to toss your computer out the window and (hopefully) has large user-adoption and/or sales.

The red area is where you don’t want to be: bloatware. This is software that’s got more features than any one user could ever find, much less make use of. It’s most likely also slow because it’s trying to do more than it’s original design ever intended. Finally, software in the red zone is quite possibly even buggier than it was when it was the green zone. Simple things that used to work perfectly now suddenly cause it to crash or get slow in the latest version.

So, now that we’ve got our framework, let’s look at some examples. You may very well completely disagree with my assessments of one or more of these. That’s fine, this is a framework to think about software and guide its management. It’s okay to want to place particular software products or versions in different places. This is a qualitative framework.

It’s clear in the above that I am a big fan of Github and Etsy and not so much of Facebook and MS Office. Why?

Github and Etsy both have stable, extremely useful offerings for their audiences. Sure, they are not perfect but when I ask myself “what software do I think is the most awesome?” they are both at or near the top. Their bugs and/or outages are tolerably rare, their UI quirks are not impenetrable and, certainly in the case of github, I spend a good portion of my day using their software without any issues.

On the flipside would be something like Facebook, which I use every day and sometimes it works right… sometimes not. But it certainly always confuses and annoys me and it’s utility has decreased dramatically over time. It went from “oh wow, there’s such and such from jr high!” to “oh, someone I haven’t talked to in 20 years sent me a virtual tree.” Having said that, Facebook does, if nothing else, constantly – and without any warning I might add – evolve. For example, there is finally a My Apps button on the developer site so I know longer have to search Google (I literally used to do this) to find the FB apps I have created.

And then there’s Microsoft Office. Oh Office, you’ve changed so much and yet… so little over the years. Office, and Outlook in particular, may be on its way to becoming “the” case study on how to feature creep or uselessly revise software to death. Sure, there are worse offenders, but are there worse offenders that have so much market adoption? How many features in MS Office do you use that didn’t exist in say… 1998? Of those new features, how many do you think work well? How many things that used to be simple make you want to punch your monitor? And the interface changes! It’s like Microsoft is saying “Pay us to learn our confusing new interface!”

Okay, enough Office bashing, next up is another favorite target of mine: Photoshop.

When I first discovered Photoshop in college (circa 3.0 or 3.05) I thought it was the single most awesomely impressive software I had ever encountered (until Quake anyway, but that’s another story). Nowadays, it is the bane of my existence every time I have to open it. My copy of CS3 is so buggy it has never stayed open long enough for my preferences to actually get saved. Think about that. I have literally never closed the app, it has always crashed first. Which, of course, is compounding madness, since I then have to reset all the preferences (yes, I could just close it now, that’s not the point, the point is it crashes a LOT). I know a lot of web developers and designers and nearly all of them feel the same way: their old swiss-army-knife of web design started going horribly wrong around the “creative suite” change and has only gotten worse since.

Enough whining, let’s talk about what this all means and what we can do about keeping our software awesome.

I am making the argument that this is the natural evolution of a piece of software: In the same sense that Information Wants to be Free, I am arguing that Software Wants to Become Bloatware. As soon as software becomes interesting and useful it gets pulled in a lot more directions: Customers and users want features, investors want constant growth and sales, and developer turnover occurs.

If this is the natural state of things, then what is to be done besides just letting software die once it gets into the red zone? Well, that is “a” solution. And an important solution to note, because just as software can die in the red zone, it can also be killed when it’s in the red zone. The best example of this, of course, is the Friendster > MySpace > Facebook progression. Both Friendster and MySpace sped over the Awesome Curve into the red zone as fast as they could and got blown away by something better.

Happily, this is not the only way to combat the crapware trend. The simplest way is the self-reboot (or “software suicide reincarnation” if you want to stick with the metaphor). This is essentially what Steve Jobs did with Mac OS when he returned to Apple and, unlike with Office, this is essentially what Microsoft did with Windows recently. Let’s look at Windows, up and to, Vista:

You can make your arguments about where XP should fall on the curve, but only the most diehard MS’ folks will try to defend Vista. In fact, many people would argue that Vista was way down the page in the negative.

But, Microsoft fixed a lot of that with Windows 7:

They restarted their curve in such a way that Vista could be thought of as being Win7′s “green” precursor. This is the most simple and obvious way to avoid software death. I would argue that it is also, the least appealing. For one thing, it’s a bit like amputation: You’re taking a big risk to save the organism, but if you wait too long it might end up dying anyway.

So what’s better? Essentially you want to make the Awesomeness Curve smaller, both vertically and horizontally. Once you’re in the blue zone, you want to be jumping to the next green zone before you can get anywhere near the red. You also want those (now smaller) bumps to be over shorter intervals of time.

How do you accomplish this? First, the four principles:

1: Resist new features.

There’s a whole school of thought that quantity of features is directly proportional to what you can charge for software. While clearly this is true in practice, that doesn’t mean that it’s not incredibly stupid. Every new feature makes your software more complex to use. If that lets you sell “training” then well, kudos to your current quarterly revenue, but somewhere along the way somebody is going to come out with a competitor product that’s easier to use and you’re going to find yourself in that red zone. And never, ever, ever impose a new feature on your entire user base because one big customer asked for it (more on this later).

I always feel like Apple’s new software presentations are campy and simplistic and, well, they are but they say something important about the company’s priorities. If Steve Jobs is bothering to walk you through seemingly simple features, that means they thought really long and hard about what features they were including and they “got rid of the crap.”

The one big exception to this rule is if many of your users are making the same complaint about something missing. I’m looking at you, lack of “Mark as Read” on the iPhone.

2. Attack bugs and slow performance like you are eradicating smallpox.

Per the above, if a new feature is taking priority over problems for your users, then your software is speeding its way into the red zone like a bad TV police chase.

3. Roll out changes fast.

There isn’t a whole lot of point in fixing bugs if you aren’t getting them to your users quickly and in the least intrusive way possible. Also: if you’re holding fixes hostage so you can “sell upgrades” with new features, I hate you.

4. Put yourself in a position to gather and measure as much data as you can.

Does anyone ever use feature X? If this button color is changed, do more people click on it? Can you, currently, answer these types of questions?

Okay, but how do I accomplish this?

First of all, the same formula isn’t going to work for every piece of software or organization. You simply have to experiment and tweak and tailor to your own needs and technology stack. Having said that, here are the seven practices I have found work pretty well:

1. Use an open source model

Even if your software isn’t licensed as open source, there’s no reason why you can’t follow the same open practices internally. Essentially this means having a really open and transparent process with good, integrated tools. It also means that your process should never, ever get in the way of someone wanting to make your software better. Do they have to ask permission or get approval to fix a bug? Really? Do they have to justify and sell their idea to you even if they’re willing to work on it in their own time? If the answer to any of these questions is “yes” then your process is working against, rather than for, your software. (Note: if you don’t trust your team at this level than either you shouldn’t have hired them or You Need to Let Go).

This essentially means making it as easy as possible for your team to check out, fork, commit, and do pull requests, as possible. If your software is complicated to run, this means keeping your docs and wikis up-to-date. If you fall under any kind of regulation, make it clear to your developers that they have to open a Bug Report/Issue and reference it in the code commit.

The other big advantage is that if you use your source control management well, you’re actively making multiple Awesome Curves that are running in parallel, so hopefully your users are only seeing the peaks.

2. Make your software extensible.

How do you resist writing a new feature for that customer who represents 20% of your sales but .5% of your installed base? You make your software extensible or modular. If your software is built to support this customization then you can simply write this feature just for this customer. But even better than that, you’ve enabled anyone to tailor your software to their needs. You have to set the ground rules and find ways to encourage good contributions, but you’re still better off working this way. An example of too much restriction is probably the iOS App Store. Too little restriction and modularization? Probably something like Drupal.

For websites, this means writing an API and client software. See any of Foursquare, Instagram, Twitter, etc.

If you’re really clever, you take the best of your module/component ecosphere and just absorb them into your main product. It’s like an achievement: “our feature was so useful, they bought us and made our feature part of the main software!” (Note that this is not dissimilar to the forking/pull request model in open source software.)

3. If at all possible, use interpreted languages

This point could be rewritten as “try not to use anything that’s compiled, built, or otherwise bottled up in a black box.” Obviously this isn’t an option for say, PC games, but it certainly is for websites and even lite desktop apps. If you do have to distribute compiled code, try to make use of app store type models such as Steam or Apple’s app stores. These models let the “store” handle the updating automatically and unobtrusively. Bouncing an icon on your user’s desktop every time they open your app is NOT unobtrusive. Obviously there are rare cases, but the point is that they should be rare, not every time the user opens the app. They’re trying to use your software for crying out loud, get out of their way!

On the web, you’re simply going to have more flexibility using Ruby or Python or PHP than you will having to say, put together a WAR, deploy it and pray. It’s 2011, the performance differences aren’t even worth discussing. Nearly everything has been shown to be scalable in some way or another. The value of those CPU cycles is pennies compared to the Ben Franklins of keeping your users happy.

Note that a lot of compiled programs make use of interpreted languages to manage or direct their compiled code. EVE Online and Firaxis’ games both make extensive use of Python to make easy, fast changes to gameplay (like changing an opponent’s hit points or something) that don’t have to involve say, the 3D rendering. This model can be, and has been, applied to the web world by writing core business logic in say, Scala and letting PHP or Django handle the actual web UI.

4. Stay focused on your stuff under the hood

If some core piece of your software is causing a lot of problems – either it’s causing bugs or making it hard to add (one of those that you thought long and hard about) features – then rewrite it! “But it’s stable, I don’t want to mess with it!” you say. To which I say, “okay, well it’s going to get worse, so you may as well minimize the pain by dealing with it now.”

One of the bigger design mistakes I have made in my career was using XML for a layout engine, essentially because the app was written in Java and everyone said “use XML!”. I think I can say, quite definitively, that the app was slower, buggier and MORE difficult to change in the future than if we had just used tables or even some kind of custom persistence object. Tons of time that should have been spent on cleaning up UI instead got spent on debugging and fixing moronic problems cross-platform parsing problems.

This type of work isn’t sexy for business owners or your sales force, but it still makes your product a lot better. Never lose sight of the fact that responsiveness and stability are every bit as much a part of your user experience as whether you used the glossy or the flat buttons.

5. Experiment

This may sound contrary to the “resist features” principle, but it’s actually not. You don’t want to resist trying features. You want to resist rolling every single one of those features out to your entire user base. You want to encourage your team to try new features and roll them out internally or to small user sets. This lets you test and experiment more and spend less time arguing about features in meetings.

The idea here is to try features quickly with small groups (or even just yourself) so you can rapidly identify and drop features that aren’t useful enough and spend lots of time awesomifying the ones that are, well, awesome. There are now “feature management” packages for most of the popular web frameworks. Pick one and use it.

6. Custom measurement and analytics

I really defer to Etsy on this. They do it really well and they’re happy to share how they do it.

7. Easy deploys

This only really applies to websites. Desktop software is its own world.

You want to make it as insanely easy and consistent to deploy code to production as possible. Last summer and fall, working on the Gardner Nelson + Partners website, we were deploying new code 10-20 times a day. That rapidly tapered off since the site isn’t that interactive (it’s essentially just a marketing site), but I wouldn’t hesitate to do that many deploys to the site if it had discussion or voting or some other high usage feature.

None of the tools out there are, as yet, perfect, but they’re a lot further along than Zip Up, FTP, Unzip, Cross Fingers. Look at things like Fabric or Capistrano or just role your own.

Deploy tools will help you with speed, but they won’t necessarily help you with consistency and predictability. For that, you want to run VMs locally. With the power of the modern desktop computer, you can replicate most production environments locally by running multiple Virtual Machines. The only things you should really need to change are CNAMES (locally via /etc/hosts) and mounting a drive to your dev workspace.

I hope this helps you think about your software, where on the Awesome Curve it lives as of today, and how to keep it in the Awesome zone.

Disagree? Did I make a factual mistake? Let me know in the comments!