Rise and Waterfall of Apple Maps

Let's talk about different ways to develop software

Hello. Can here. Today we talk software and maps.

We talked about the 2019 WWD last week. Yet, it was such a densely packed presentation, it is worth pulling out a few more threads. During the presentation and the Apple pressers afterwards, one thing that came to my attention is how Apple has redesigned its Maps app again.

If that phrase sound familiar, it is because I think this is the second time Apple is announcing it’s built the map experience from the ground up, after its initial less-than-stellar lunch. This time, Apple says, its maps are even better. Now there’s Apple’s version of Street View which is sleeker. The maps have more detail. It all sounds good, but I do worry if Apple really has what it takes to develop this type of software, and more importantly the infrastructure behind it, in a way that can compete with Google.

Tech companies like Apple are giant behemoths and the way software is developed does affect the kind of software that comes out the door. We talked about this a bit in the context of Service Oriented Architecture Amazon had followed for years, and how it enabled them to build AWS. But there’s more to it, so let’s discuss two different ways.

Down the Waterfall

You can divide the ways you develop and launch big software products into two. The first is one is basically how you think you’d develop and launch software; talk to some people who you think will use your software, collect those requirements into a document. Then you talk to your software people, tell them what needs to be done, they argue with you a bit why it’s so hard to do X and Y, but eventually people agree on a specification. Then, the software people go and do their thing for a few weeks (months, years, whatever) and you have software ready to launch.

This approach is called waterfall where there are sequential steps (requirements gathering, planning, development, testing) and your software falls from step to step.

Of course, this approach has its problems, largely being that you do really not know how your users are going to use (and equally important, abuse) your software before it is delivered in their hands. The moment people start interacting with it, they will realize their most requested feature is pointless, but if you could do this other thing, they’d happily pay double.

Then, you can adopt a more iterative approach where the sequential steps are turned into smaller cycles. Instead of developing a giant specification that no one fully agreed on (but rather, gave up discussing on in reality), you develop something and put it in front of people. They tinker with it a bit, and see what they like and they don’t. You then take this feedback to your team, and they tinker a bit more, then it goes.

Can do Agile instead?

This approach is called agile and has been the more common approach to software development lately. The main idea is your iterative cycles are much, much smaller. Ideally weeks or days instead of the months or years in the waterfall mode.

There are of course some costs to this model. The obvious one is, there’s a ton more management you need to do, constantly collecting and collating feedback from your users and relaying it to your developers. Your software people need to be more in contact with the users, which they may or may not like. You also need to educate your users a bit too; they need to be OK with their products being constantly in flux, with things coming and going at times. The much maligned Move Fast and Break Things slogan is a good way to summarize this model.

In the Software Eats the World of online, most stuff gets built with an agile model now. There are some baseline requirements, of course, that every agile product needs to cover. For a consumer product, for example, you need to build some account management things, and for enterprise software there are regulations and standards you have to adhere to no matter what. Yet, the bigger bulk of the value add is slowly moving to the agile-y developed part.

Agile is still mostly about developing the said software, but you can also see how the delivery methods does play into it. In the waterfall world, the feedback came much later, so it didn’t matter if the software was shrink-wrap software or was downloaded. In the Agile world, however, you need the delivery and the feedback as soon as possible. In fact, if you could skip the delivery step altogether and immediately onboard your customers on to the new version, that’d tighten the loop even further.

41 Shades of Blue

For Google, this method of developing and delivering software is ingrained in their culture. In fact, the company was so adamant in rationalizing the agile process and feedback collection, that at some point it’d famously try testing 41 shades of blue. If your software is essentially a web app that’s accessed by thin clients (like web browsers), you can skip the feedback part entirely and just throw out automatically generated different versions of the same thing and see what sticks. That’s partly crazy, but really, why not?

Apple, on the other hand, has the DNA of delivering software in yearly cycles that generally correspond to their hardware launches. Every June, you get a sneak peek at the new stuff, and by September you can put in your phone along with the new hardware to go with it.

Now, the company has been working to make development of its new apps decoupled from OS updates, but you can still see the organizational culture is much, much different than Google.

This brings us back to Apple Maps. Now, it’s true that on iOS that Apple Maps has a larger market share, but that's mostly a function of immutable defaults. Yet, you’d be hard pressed to find anyone who finds Apple’s product to be as good as Google Maps. The fact that Apple itself had to apologize and tell people that Google Maps would soon be coming only speaks to the company’s initial confidence in its product, at least initially.

Apple Maps, Back Again

It’s hard to tell whether Apple Maps is as good as Google Maps now. For some use cases, it probably is. But, speaking from experience and some data I had seen when I was at Uber, when it comes to rigorous users, Apple Maps simply doesn’t cut it. My personal experience echoes the same; every city I travel in I make a small concerted effort to switch to Apple Maps first but then soon give up switch to Google Maps. Sometimes it is because Apple Maps doesn’t have transit information, and sometimes its location database is simply lacking in quality.

I am aware I am being a bit unfair to Apple here, and mixing software development practices (waterfall vs. agile) with what’s essentially building a big database that you need to update. But I’d argue, the culture that surrounds software development permeates into how the said database that supports that product is maintained too.

Moreover, It’s true Google had a huge headstart in building maps compared to Apple. There is some diseconomies of scale here, no matter how hard you try, you just need to spend a bunch of time building a ton of stuff before you get to something usable. In addition, Google Maps being a default on Android and its relatively generous attitude to data collection does help Google in ways that Apple will not even try. There could be some smart tricks you can do here with anonymization, but I doubt if they’d ever get you the fidelity of data you’d get from simply tracking your users’ every more forever.

Apple will of course keep updating its location database in the server every day, and its transit database will better too. Yet, looking at what Apple has demoed at WWDC and how it is presented, I can’t help but notice that the Cupertino company still hasn’t fully came to appreciate how people came to expect their products to get better every day, not every year. This is especially key for something like maps, where the info becomes stale the moment you put in the database.

Former Apple employee Justin O’Beirne has written many in-depth comparisons of Apple and Google Maps. One of his concerns, in his latest essay was whether Apple was too focused on shapes, which are pleasing, and Google on information, which is useful. I think that comparison does speak to what different things are important to each company. But I also think as important as the priorities is how the work gets done, and how it affects the outcome. Apple has its task set out for it.

---

What I’m Reading

The day we discovered our parents were Russian spies: Reading about spycraft is always fun. But then you realize, spies are people too. They have lives outside of work, friends, families, and sometimes, kids. This is a fascinating story about two Canadian kids who, one day, learn that their parents are actually Russian spies and have their entire lives taken away from them. If you’ve watched the famous TV show Americans, this is the story it is loosely based on:

The programme was the only one of its kind in international espionage. (Many assumed it had been stopped, until the 2010 FBI swoop.) Many intelligence agencies use agents operating without diplomatic cover; some have recruited second-generation immigrants already living abroad, but the Russians have been the only ones to train agents to pretend to be foreigners. Canada was a common place for the illegals to go, to build up their “legend” of being an ordinary western citizen before being deployed to target countries, often the US or Britain

What I Learned Writing a Book: My twice-manager and long-time friend Will Larson’s book, An Elegant Puzzle is finally out. Will is a compassionate manager first, but also a very analytical thinker, who loves analyzing the human and systemic aspects of software development. He’s been writing on his blog for years, and this newsletter is partly inspired by his writings as well. I hope you take the time to read his book, or check out this review. And in the mean time, here is Will about the process of writing a book.

There is this sort of classic bind in life that sometimes your biggest opportunities arrive when you’re least equipped to take advantage. Towards the end of finishing the book, I found my patience and joy in writing declined – I was burning out – which isn’t too helpful as my continued writing is a big part of marketing the book, and it’s also a unique opportunity to get more folks reading this humble blog if I can keep writing good things.