Building Software and Building Bridges

We have a problem. People can't get from one area of town to a neighboring area because there is a river in between and no road. So let's build a bridge.

Step 1: Requirements
We'll get detailed requirements from civil engineers and government officials, including environmental constraints, safety guidelines, traffic considerations, and all sorts of other arcana.

Step 2: Design
We'll have architects, designers, and engineers create a plan that meets all of the criteria. We'll do a tremendous amount of pre-planning. We'll take public opinion surveys. We'll invest a huge amount of time and energy up front to ensure that everyone knows exactly what kind of bridge we're building and exactly how much it will cost. Our engineers and designers will have estimates of exactly how many pounds of concrete we'll need. And how many nails. And which suppliers the nails will be coming from. And backup nail suppliers in case something happens to the primary supplier.

Step 3: Implementation
Contractors go to work. Using the detailed design a team of professionals can reasonably be expected to deliver this massive project on time, and on budget. And we have our bridge!

Hmmm...

Requirements--> Design--> Implementation

Does that sound familiar? Oh yeah! It's waterfall development! And it doesn't work for software.

Since the beginning, we've tried to wrap traditional project management and construction metaphors around software development. It sounds reasonable - in both cases we have teams of designers and engineers delivering a very complex, expensive solution over a long period of time. In the construction world, if we're over budget or late, it's probably due to some flaw in the requirements or design process. If only we had invested more time up front! As software projects blow past their budgets and deadlines (whoosh!), companies also often react by investing more up front. We get long, detailed requirements documents that no one reads. Using construction techniques to solve software problems doesn't work because it's a flawed analogy.

Let's try that bridge again, but with software.

We're going to start by focusing on the problem to solve: get people from A to B. With software, the solution isn't necessarily as obvious as it is in the physical world. Maybe we need a bridge. But maybe we need a ferry. Or a helicopter service. Or maybe we should just move the two pieces of land closer together. Or freeze the river.

Customers speak in terms of solutions: I want a bridge. I want a bigger kitchen. But with software we know to be wary of this: unlike the physical world, the users of software often do not have a good intuitive understanding of what's possible. So while they speak in terms of functionality and solutions, it's our job to root out the real problem and come up with an appropriate solution.

But let's say a bridge is the right answer and we've settled on the bridge we want to build. It's big, it's complicated. Unlike building a real bridge, spending lots and lots of time up front on our software bridge will not lead to accurate estimates for our bridge's construction. There are lots of reasons for this: programming is fundamentally an individual task and developers work at dramatically different levels of productivity. We may not know which developers are working on our bridge. Or the ones that provide the estimate may not deliver the parts they estimated.

Furthermore, software complexity increases exponentially with the size of the project. A 10,000 line program is hundreds of times more complex than a 1,000 line program. But a 10,000sqft house is linearly more complex than a 1,000sqft house*.

The result is we have a unique statistical challenge when estimating software. Michael Church on Hacker News explains it beautifully:

Let's say that you have 20 tasks. Each involves rolling a 10-sided die. If it's a 1 through 8, wait that number of minutes. If it's a 9, wait 15 minutes. If it's a 10, wait an hour. 

How long is this string of tasks going to take? Summing the median time expectancy, we get a sum 110 minutes, because the median time for a task is 5.5 minutes. The actual expected time to completion is 222 minutes, with 5+ hours not being unreasonable if one rolls a lot of 9's and 10's.

This is an obvious example where summing the median expected time for the tasks is ridiculous, but it's exactly what people do when they compute time estimates, even though the reality on the field is that the time-cost distribution has a lot more weight on the right. (That is, it's more common for a "6-month" project to take 8 months than 4. In statistics-wonk terms, the distribution is "log-normal".) 

Software estimates are generally computed (implicitly) by summing the good-case (25th to 50th percentile) times-to-completion, assuming perfect parallelism with no communication overhead, and with a tendency for unexpected tasks, undocumented responsibilities, and bugs to be overlooked outright. 

Software teams will not be able to tell you the number of nails needed. Or the pounds of concrete. Software estimates are unintuitive and must account for a great degree of uncertainty.

Good software teams use a completely different set of techniques to battle uncertainty: They ship frequently (there are not many shippable increments when building a bridge), run lots of experiments, and integrate the design, implementation, validation, and requirements phases together into one process. We encourage iterative, creative thinking. We want to try lots of things, fail fast, and move on. It's not unusual to read something like this about building software (from Little Bets):

Learn by doing. Fail quickly to learn fast. Develop experiments and prototypes to gather insights, identify problems, and build up creative ideas, like Beethoven did to in order to discover new musical styles and forms.

It's not surprising that the waterfall approach to software has failed. Waterfall was taken from the world of construction, but construction is simply not analogous to software. We need new processes.

It's only in the last ten years with the emergence of Agile, Kanban, rapid prototyping, and general acceptance of iterative, fail-fast approaches that software development has come into its own. We are good at building bridges, and we're finally getting good at building software.

* I was a little uncomfortable making this assertion without knowing much about construction, so I called up a friend who is a project manager for medium/large sized construction projects (industrial parks, housing developments, etc) and discussed. He backed the claim.

No Bugs != Quality

A low bug count is not a good indicator of quality software. Lack of typos and grammatical errors is not indicative of a quality book.

If your software has nagging "quality problems", driving the open bug count to zero probably won't be much help (not least because it only addresses the bugs you've found - not the multitude inevitably lurking in obscure code paths). If the software is hard to use; if it doesn't solve the problem it was designed to solve; if it's slow; if you pay a huge engineering tax whenever you make a change because the code base is spaghetti; then bug count may not be your problem.

In fact, a high bug count isn't even a reliable indicator of poor quality. Google Chrome, the world's second most popular browser, has over 32 thousand open issues.

I'm all for keeping bug counts low - fewer bugs is better than more bugs - but if you have a large number of infrequently-reported bugs, then bug count is little more than a vanity metric. 

Fixing every outstanding edge-case bugs will not create happy users out of net detractors. Playing whac-a-mole with bugs is ineffective. Quality issues demand stepping back and taking different approaches. Bugs are symptoms, not causes.

Localization (or: Localisation) Tip

I just learned something from our documentation team: Try to avoid using gerunds in UI text because they are difficult to localize & translate. While they certainly aren't a challenge for great translators, I'm told they can be misinterpreted by mediocre translators - like the ones that outsourced translating services might use.

"Creating a page" --> "How to create a page"
"Click here for help resolving this issue" --> "Click here for help with this issue"

How to Improve Chrome Web App Adoption

There was big news in the browser world this month, as Google's Chrome browser eclipsed Firefox's market share, making is the #2 most popular browser in the world. Google's goals with regard to Chrome have always been clear. As Peter Kasting, a founding member of the Chrome team at Google, puts it:

"The primary goal of Chrome is to make the web advance as much and as quickly as possible"

And they've been doing that very effectively, as I've blogged about before.

While I don't doubt this as the primary motivation for building the browser, there are clearly some tangential opportunities that Google is exploring. For instance, there is a fascination theory that the Googlebot (the crawler responsible for maintaining Google's search index) is in fact running Chrome under the hood in order to index JavaScript and other dynamic content.

There is also the Chrome Web Store, which has emerged in over the last 12 months as a way for Chrome users to browser through a (very) lightly curated selection of web "apps" and install them to Chrome - an app store in the footsteps of Apple, for the browser & web. The store appears to have about 65 million users (though it's unclear what counts as a user) and about 18,000 apps available.

I have some theories about Google's strategic goals of the Chrome store (in all likelihood it's to support  Chrome OS, but it might not be. What else, say you? To drive Chrome adoption? To turn a profit by pushing Google Checkout? To simply "advance the web"?) but ultimately we can make the safe assumption that the success of the Chrome Web Store is predicated on people installing and using Chrome apps. More app installs = execution of strategy (whatever it is).

So how is the store doing? With 65 million users, based on Chrome's ~25% market share and the 2bn worldwide internet users, about 13% of Chrome users have made use of the store. Given how the store works today I'm actually surprised it's that high, but I'm guessing that iPhone users' adoption of the Apple app store is close to 100% and that the Google team is not satisfying mucking around at 13% adoption.

Let's see if we can help them out.

But first, it's worth noting that there are really easy ways to drive Chrome app adoption: aggressively promote the store from within Chrome itself, show app results in Google search results, and in general promote the store across Google properties. However Google has wisely resisted such cheap promotion in the past (edit: maybe not), so this discussion is focused on how the Chrome store can succeed on its own merits, not on Google marketing it to a captive audience.

So let's try and divine what exactly a "Chrome App" is, versus a "normal" web app that's just run through the browser. I'll go ahead and install the ever-present Angry Birds (which over 1m Chrome users have also done). It's easy enough through the Chrome Store, and here's the end result:

I installed Angry Birds!

Voilà! I now have an Angry Birds icon available whenever I open a new Chrome tab.

When I click it, Chrome navigates to http://chrome.angrybirds.com where I can, surprise, surprise, play Angry Birds. It's worth noting that I can just as easily hit this URL without the Web App installed. In fact, I can even hit in IE and it works fine.

So what's the big deal? Surely there is something to Chrome Web Apps other than a handy link on new browser tabs, right? Well, there is. The difference is near the bottom of the screen, and here's what it says when I have the app installed:

Ah-ha! It's installing the offline version. And indeed, without the app installed, I see this instead:

In fact, it's the same message I see in IE:

Hmmm, well that seems...minor. The handy shortcut is fine and good, and apparently the app also gets access to some local storage, but if that's it then the store may be in for a lot of comments like this, from a Google's "Why You Should Create an App" video:

But Angry Birds is just one example - there must be more, right? Let's hear from Google directly, which will surely convince us that the app store is more than a directory of useful web sites.

Here is how Google describes the benefits of a web app, buried deep in an FAQ:

Why would someone install a web app instead of just using a bookmark or typing in a URL?
Installing an app ensures it is launchable from the New Tab Page via the Chrome apps launcher. Installing an app also allows you to grant it privileges such as unlimited local storage and background pages.

That's pretty much the entirety of Google's explanation of why Chrome apps exist. Even the way the question is posed makes the apps sound ridiculous.

To encourage app installs, the benefits of doing so need to be obvious and tangible. Right now they are neither. There are in fact real benefits to the app approach, but Google has seemingly little interest in conveying them to end users. As a result, users view apps as glorified bookmarks.

The situation for developers is no better. The developer portal describes the problem apps solve as "requests for permission are annoying" (really, this is what it says). Again, benefits are not spelled out and developers are left guessing as to why, exactly, they would make an app.

Ask an iOS developer what the benefits of a native app are (even shimmed HTML5 apps made with technologies like PhoneGap). They'll say:

• Frictionless purchasing
• In-app payments
• Rich APIs
• Exposure via the App Store
• Available offline/no network lag
• (and yes) Elevated permissions

In fact, Chrome Apps offer many of the same benefits but they are poorly explained to both users and developers. Paid apps, integrated with Google Wallet, are available (albeit poorly adopted - this was literally the only example I could find after 20 minutes of searching), as is an in-app payments API.

Google just needs to explain this better. And it's not hard. Here's 10 minutes of effort in Balsamiq:

Google needs to make the benefits clearer.

But even existing apps are not taking advantage of these benefits. For instance, Prezi is a fairly popular productivity app in the store, with about 50,000 users. As far as I can tell the app is literally a glorified bookmark, just linking to Prezi.com. I still have to sign up (create a username and password) for Prezi.com, and if I want to purchase a paid version I get a form that looks like this:

Wowza! Lots of form fields! Given that I have installed this as a Chrome app, shouldn't Prezi know something about who I am, and have some sort of access to my data? At best, signing up should be a one-click process (similar to purchasing an app in the first place) and at worst, couldn't it at least have an account already created for me and pre-populate some of the fields? It's unclear to me how much of this is possible with the current APIs, but this type of thing should be the default, expected behavior for anything installed as an application (and only applications that take advantage of the benefits of being an app should be featured in the store). Rapid, secure registration and payment are clear benefits to both users and developers of apps.

If I haven't installed Prezi as an app, Google should allow developers to easily incorporate the "Add to Chrome" button to their site, which would allow the site to then take advantage of easy registration and payment options. Imagine if, above all of those Prezi registration fields, there was a button:

A user could then choose between simply clicking this button, or filling out then entire form. I'd click the button every time for rapid, safe, and centralized payment and registration.

Finally, the store itself needs better curation. Browsing around the Games category, it seems half of the games are simply links to little Flash games surrounded by ads - hardly the slick HTML5 "apps" Google wants to promote. With a higher threshold for quality, and some improved discovery features, the store could quickly become a great way to find new services.

In conclusion, the Chrome store has great potential but needs to make changes to avoid becoming nothing more than a cool bookmarking service. Specifically:

• Make the benefits of apps clearer to users and developers
• Create better registration and payment APIs, and help developers incorporate them into existing services
• Create an Add to Chrome button that can be used outside of the store itself
• Improve quality and discoverability of apps in the store

I look forward to see how store adoption grows, and how this new take on the app concept plays into Google's larger strategy and offerings.

If you're not paying for it...

If you're not paying for it, you're not the customer. You're the product being sold.
- Blue Beetle, via Metafilter

Think about this when using Facebook, Google, or any (profitable) free service.

There is nothing fundamentally wrong with this model, but we should periodically step back and evaluate the trade-offs we make to understand whether we're still comfortable with them. Be safe and happy in this new year.

DOET Shower

I stayed at a friend's apartment a few weeks ago. It is difficult to describe the decor, but if my grandmother and Master P were forced to collaboratively design an apartment, his place is what you might get:

Walls covered in paint made from melted silver, gold dragon faucet heads roaring out of the wet-bar sink, all trimmed with flower-print or toile curtains. That sort of thing.

The shower is, of course, also over-the-top; one of those awesome luxury showers with heads and nozzles jutting out every which-way from the granite walls. Sounds like great fun, but when it came time to actually use it, I was confronted with the following:

Not only did I fail to figure out how to control the temperature and which shower heads were active, but I couldn't even figure out how to turn the thing on and off! I was assaulted from all sides by water of all different temperatures during the minutes of fiddling it took for me to turn this stupid thing off.

I was horrified enough by this set of controls that I actually bothered to take this photo to document the insanity.

Yesterday I started reading The Design of Everyday Things by Don Norman and, to my delight, came upon the following diagram:

With the wonderful caption: "What do you do here? Why would anyone dream up this scheme?"

I am very much looking forward to reading this book.