Augmented reality and the exocortex

With Apple leaking their AR project timeline, CNBC has a roundup of all the players trying to make an entry in this category. Unanswered is why all of these companies are chasing a dream that, so far, hasn’t delivered.

In Charles Stross’s Accelerando, a partly tongue in cheek take on the road to a technological singularity, a primary component of the transhumanist future is the “exocortex,” a component of your mind that exists outside of the brain you were born with. While the point of science fiction is not, for me, to be predictive, I found Accelerando full of surprisingly plausible extrapolations.

The smartphone was the first meaningful step toward an exocortex. It “remembers” things for you, like meetings and tasks you mean to do in the future. It communicates and receives data on your behalf, amplifying the reach of your ideas. But the exocortex is not, in this example, mere local hardware. The smartphone connects you to cloud-based mapping platforms, extending your mind’s ability to navigate. Your exocortex, comprised of a suite of local and remote applications, allows you to “know” how to reach a particular place you’ve never visited.

So what we get from the smartphone is a meaningful expansion of our mind’s base abilities, in an interface which is nearly as portable as our mind itself.

The interface between our mind and our exocortex is, for now, our eyes. The eyes are the highest bandwidth channels into the brain our biology provides as stock—10 megabits of data per second. So if you want to get a large quantity of data back into the brain, the eyes are the ticket.

This is why so much effort has gone into screen technology since the advent of the iPhone, and why the iPhone was so category defining: the entire surface of the product could be directed toward information transmission to the brain via the eyes. Much more rewarding than the narrow windows standard to the Blackberry devices of the day.

But there are limits here: you have to hold the device to see the input, and you have to choose between the device’s input and data from the outside world. This creates friction.

AR is the inevitable next step to network our brains with a growing exocortex. We’re still far away from direct neurological interfaces, and we’re far from maxing out the potential of the optical channel.

This category will happen and will usher in all new ways of doing everything, as much as the smartphone did. The only questions are:

  • How long will it take to meaningfully miniaturize the hardware to solve this in an appealing way?
  • What is the level of software maturity needed to bring this into mainstream use? In other words, how far are we from killer apps?
  • What are the input devices needed to comfortably send data back out of your mind in the absence of your fingers on a screen?

“Smartphone” was a category before the iPhone. Blackberry, Palm, HTC, Danger and others had internet-enabled communicators years before 2007. Like today’s AR devices, though, these were sold in mostly niche, business-focused markets. It would take a breakthrough in miniaturization and interaction design to make this technology ubiquitous.

It seems we’re waiting on the same event for augmented reality.

By 2030, we all have AR headsets, though. I’m willing to bet anything on that.

Explainer Technical

How to Ship a Software Project

I’ve spent the last 14 years building software, off and on. Over that period I’ve been on the hook for dozens of ship dates. Some I missed. Many I hit.

Through all those adventures, I’ve settled on a basic process I think anyone can use to get from deep-in-the-weeds to a triumphant ship. None of this is especially innovative. Plenty of people likely ship using some variation of this exact procedure. But I wanted to write it up in case it was useful.

1. Pick a ship date—but don’t get attached to it

Start by choosing a date on which it would be nice to have shipped your project. Any criteria is valid here. Business needs, deadlines imposed by programs to which you want to apply, even press strategy.

But don’t get too attached to this ship date. You have no idea if you can make it. At this point it’s an experimental constraint, which will guide the rest of your planning process.

2. Determine the minimally viable feature set your project needs for a successful ship

What does the audience of your project need to be better off than if you’d never shipped the project at all? What is the simplest feature set you can deliver to make an impact?

by Henrik Crisp

You’re reading this because, presumably, you would like to ship. So it’s essential you understand that you can’t immediately ship everything your mind imagines. You can’t ship perfection. Perfection and shipping hate one another, so you have to pick one. I suggest picking ship, but that’s up to you.

Shipping requires hard choices. The more things you try to bundle into a shipping project, the more risk you incur. The risk multiplies invisibly, as it’s impossible to know ahead of time about complex interactions that produce bugs, reduce performance, or otherwise introduce surprises.

The fewer things you try to ship at once, the less risk you incur. So when you make the list of things you want to see in your first ship, do everything you can to keep it as short as possible.

3. List all of the dependencies that must be satisfied for your minimally viable feature set

What needs to exist for these features to work? How much already exists? Get your mind around all the dependent tasks, from things that need to be built, to things that must be bought, to things that must be designed, in order for these features to be ready for public consumption. With luck, you’ve already got some of these dependencies handled.

Can you license or purchase things instead of building them yourself? Can you leverage open source software rather than rolling your own solutions? Think through how many off-the-shelf opportunities exist to satisfy your dependencies. But also remember there’s no free lunch: integrating outside resources can still be costly.

4. Estimate how much time it will take to satisfy your dependencies—then multiply

Software development time estimates are comically error-prone. But if you price the estimation risk into your estimate, you can earn yourself some breathing room. There will be bugs that keep coming back. There will be surprises as you integrate third-party tools and content. There will be tasks that seemed easy at the outset, but whose implementation reveals a raft of additional complexity.

That’s life in the software business.

As you create an inventory of your dependencies and the time you estimate they’ll need to cook, multiply by 2.5.

Maybe that seems excessive. But it’s a concession to the fact that our frail meat brains are bad at storing and modeling the total complexity of a software system. When you made your initial guess, you were quite possibly ignoring more than half the picture. Price that limited perspective into your final guess.

Or don’t. It’s your ship. You can use whatever multiple you feel comfortable with here. Long experience tells me that for my estimates, though, I usually want 2.5x.

Don’t forget time for testing your project ahead of ship. I can’t tell you how long this will take, since different environments have different constraints. If you’re shipping native code for approval in the iOS App Store, for example, you’ll want to do much more thorough testing than if you’re shipping a web app you can update at-will.

You’ll also want to budget time to make fixes based on what you learn in the QA process.

5. Add up your time estimates and compare the timeline to your ship date

If you’re very lucky, your time estimates and your ship date mesh perfectly.

But you’re probably not lucky. You’re working with software, and software delights in thwarting our optimism. What if your requirements push far past the ship date?

You’re going to be tempted to manipulate the estimates. Don’t do this. There’s a reason we estimate in pieces and add things up, instead of working backwards from the ship date.

In this process, here are all the things we’ve considered in order from most real to least real:

  1. The dependencies for our desired features
  2. The minimally viable feature set
  3. The time estimates
  4. The ship date

The ship date is the least real thing we’re dealing with! Don’t let it drive.

That said, if you absolutely must treat the ship date as a hard constraint, you have options. None of them include goosing the estimates.

6. Make hard choices: trim scope or move the ship date

I know. You want a pony.


But now you know what the pony costs.

You’re going to ship the pony 18 months later than you would have liked. Are you going to have enough money to survive for that extra 18 months? Will you give up an important competitive advantage by taking that extra 18 months? Are you OK waiting 18 extra months before getting feedback from customers about whether you’re even on the right track?

Maybe you’re fine moving the ship date. Sometimes that’s the right call.

But often, this is the point in the exercise where you take out your knife and start trimming scope. Maybe you’re not going to ship a pony. Maybe it’s time to ship a bicycle instead. With the knowledge of the time and financial cost of your minimally viable feature set, maybe you can find inspiration to pare down even more.

Trim scope until your estimates for the remaining work—which you have not goosed—give you a few days of margin under your ship date.

Now you can get to work, having a clear idea of what’s worth prioritizing and what can wait. You can repeat this process whenever you feel your project getting off track or losing steam. It helps me to track my requirements and dependencies on something tactile, like notecards or sticky notes, but you can document the process you’ve gone through using whatever systems make sense for you and your team.

But, Danilo, this isn’t the agile/scrum/[cargo cult methodology] way!

Whatever, man. I’m sure it isn’t. This is the way I know to get a project out the door on a date agreed upon by all parties, with scope documented for all parties, with trade-offs understood by all parties.

Within that, I’ve seen it work alongside tools like sprints, planning meetings, stand-ups, and retrospectives. I really like doing all of those. If you have existing systems you like to use to communicate and collaborate, you can keep them.

But you need a way to understand the relationship between costs, scope and outcomes, and to communicate those constraints across all functions. This is the basic approach I’ve long used for that. I hope it’s helpful in your adventures.

Further reading:

1.0 by Rands: “Shipping a 1.0 product isn’t going to kill you, but it will try.”


Why Apple chooses thin devices over longer battery life

Apple is never happier than when announcing a flagship product has been made just a little thinner.

It happened last week with the Apple Watch, which is 0.7mm thinner than its predecessors. Before that, the iPhone lost more than half its thickness over the course of a decade. The iPad has slimmed down significantly from its first iteration. And who could forget the introduction of the MacBook Air, plucked with fanfare from a manilla envelope.

Steve Jobs loved a good reveal.

Every time this happens, you can set your watch by a chorus of onlookers and faithful Apple customers both asking the same thing:

Why can’t we have a few more hours of battery life instead?

With all the extra volume Apple’s miniaturizations have carved out over the last ten years, it’s conceivable they could have doubled the battery capacity of their most popular products. Smaller components means the possibility of more room to store energy.

Instead, we get a march toward smaller and lighter devices.

There’s a strategic reason for this which can teach us a lot about 21st century economics.

Information goods

Information technology pervades every aspect of our culture and economy. Even physical products now have deep information roots. As Paul Mason’s Postcapitalism describes:

In hi-tech engineering, before a single piece of metal is shaped, objects are designed virtually, tested virtually and even ‘manufactured’ virtually — the whole process modelled from start to finish — on computers. The mistakes are discovered and rectified at the design stage, in a way that was impossible before 3D simulations came about.

Which means that the outcome of a research and development process can now be cheaply duplicated by anyone who has access to the basic machinery to convert digital plans and schematics into finished goods. Competitors can produce alternatives or counterfeits that cost little more than the raw materials, tools and labor necessary. Because these competitors have minimal R&D costs, they can undercut the original producer, destroying their profit margins.

In Mason’s words, information tech “corrodes” prices over the long term.

Many who shop on Amazon or Ebay have first hand experience with this phenomenon. Both services are rife with counterfeits sold as the genuine products of the brands they’re emulating, often at discount. This presents meaningful challenges for small companies selling basic hardware. Elevation Lab designed a clever but easy to manufacture hook for storing headphones beneath your desk. They quickly found themselves competing with counterfeiters:

They literally reverse engineered it, made steel compression molds, made the logo wrong, used fake 3M adhesive that’s very thin and was diecut smaller than the top (measure once, cut twice), they use a lower durometer silicone so it flexes more, its has huge mold parting lines, and the packaging is literally photocopied then reprinted (you can tell by the lack of image contrast). And they had to apply a big sticker to cover our SKU with theirs. But to the untrained eye, it would pass.

Elevation Lab was unable to maintain a monopoly on the basic inputs that yielded their product. The design schematics, manufacturing tooling, and even packaging could be approximated by a third party wielding the power of information-based design and production.

It is into this future that Apple is sailing.

Apple’s monopolies

Here it is helpful to define our terms.

Monopoly is a loaded word. The Bell Telephone Company once held an absolute monopoly on all US telephone service. Microsoft had a monopoly on computer software in the workplace, controlling more than 90% of desktops in the 1990’s.

But monopoly can exist even without this level of market dominance. You can be the exclusive purveyor of a product without being the exclusive purveyor to an entire market.

This is the position where Apple finds itself. It doesn’t come close to selling all of the world’s smartphones.

Yet it maintains a tight control over several inputs that make an iPhone:

  • iOS, the operating system that drives all its non-Mac computers
  • Their processes and designs for creating the custom chips that now drive the iPhone
  • Expert hardware engineers who can push the state of the art into new scales
  • Processes, equipment and raw materials for producing consumer hardware at extraordinary scale, to extremely fine tolerances.

Miniaturization as monopoly

So why is Apple making things thinner, rather than expanding battery life? Why are they sacrificing headphone ports to push their designs into thinner and thinner dimensions?

The answer is that anyone can make bulky tech with massive battery capacity.

But no one can build devices that are as miniaturized as Apple’s.

Through miniaturization, Apple creates products whose subjective experience of niceness cannot be matched. By exclusive control of cutting edge, global-scale manufacturing processes and the silicon necessary to produce both powerful performance and good enough battery life, coupled with an exclusive operating system written to match and enhance the capabilities of the hardware, only Apple can make iPhones.

Which means if you want a phone that feels this nice, you have to pay prices set exclusively by Apple.

Apple is staking its future on its ability to make products that are seamlessly integrated and ever smaller, lighter, and thinner. For now, it’s working. They’re worth a trillion dollars. As manufacturing processes advance and evolve, Apple will have to evolve along with them.