Technology growth is a pyramid

Growing up in what’s now called “Silicon Valley”, I’ve been surrounded by technology my entire life. One of my ongoing side studies has been observing and predicting the growth and direction of technology.

I used to think technology growth was linear or exponential – every update an improvement over what came before. After noticing things lacking in my iPhone that I’d liked in my Palm Pilot, I started thinking technology growth was cyclical.

Now, looking back at the history of our recent technological development, and farther back at the technology of older civilizations, I’ve realized that technology growth isn’t linear, exponential, or cyclical. It’s more like a pyramid of dependencies that must be continually maintained.

Technology doesn’t grow – it’s built based on the abilities and needs of a society at a given moment, and rapidlydeteriorates from there. Any given technology’s life is more comparable to a piano note’s envelope than to a linear graph: hit the note and it’s loud at first, but rapidly decays unless you keep hitting it. Technology is the same: any given technology, be it a phone, toaster, space ship, or piece of software, requires constant maintenance and development, or it rusts, rots, or otherwise deteriorates, pretty rapidly. How long would your phone work without a cell tower or electricity?

In addition, higher-level technology is built, like a pyramid, atop lower-level technology. This is very visible in software, where applications are built on top of libraries and frameworks that are built on protocols that run on operating systems that run on more protocols that run on modular hardware that’s built of specially-engineered materials that are skillfully formed from ores that are skillfully mined from the ground (or other sources), that require power provided by other hardware passed over specially formed ores also mined from the ground. If any one of these levels isn’t maintained, the higher levels rapidly, often immediately, cease to function.

This means that there’s a baseline of technology, which is roughly that which any individual can build him/herself from naturally available materials. From there, people working together can build levels of technology. If any of the groups fails to maintain their part of the technology pyramid, their part must either be rapidly replaced (in place or by an equivalent to which the dependent pieces can quickly move), or the pyramid collapses.

This has a few implications I find interesting:

  • Space flight: If someone isn’t actively trying to get to space and has a need to do so, that technology will deteriorate. We went to the moon (and some believe we didn’t), and then stopped going. Elon Musk said in a TED interview that the reason he started SpaceX is that space travel isn’t inevitable (pointing out that we went to the moon, then stopped).
  • We might not be (in fact I think it’s likely) the first technologically advanced civilization on Earth. It’s possible, even probable, that other civilizations have left the planet. If the smart people of a society left and the technology was forgotten, we’re the descendants of the people that didn’t leave. I think the Egyptians (or another group around the same time) discovered a means of lifting heavy rocks and sand, which, given the presence of similar structures around the globe at the time, was probably common knowledge. It may well have enabled them to travel across the globe, or off it. Somehow, that technological knowledge was forgotten, and now we don’t know how to build pyramids.
  • Colonizing Mars will be more like a frontier farming community than like Star Trek. Any technology on Mars would have to be shipped from Earth. You couldn’t build, or even fix, the most basic PC on Mars. There’s no Intel to build a chip, nobody to manufacture the case, and really nobody to build or maintain a power plant. Plus, if you’re on Mars, your biggest concern is how to grow food and breathe – the need for a PC would be vastly lessened, and it would therefore not be maintained.
  • Last but not least, if you end up in a primitive village on another planet, you’re not going to make them technologically advanced. If you’re lucky, you’ll make them sandwiches. 😉

“Grab The Nearest Device” Design

When designing Yet Another Wifi App (YAWA), I subconsciously had a design principle in mind that eventually was coded into the development process: the version numbers were kept in sync and all platforms had the same feature set.

I now call this “Grab The Nearest Device” design, because when I want to do something, I want to grab the nearest device. What’s the point of having an iPhone app if I can’t do the thing I just grabbed the device to do? I personally think that’s worse than not having an iPhone app because it makes me spend time trying to do something I then find I cannot. For example, say I want to add a new account at my bank. I pick up the iPhone (or run the app on my iPad), and search around for the “add account” feature. Can’t find it. Now I have to go get the computer and do it on the web site, whereas without the option of an app, I would have just gone to the computer in the first place. Next time, if I’m smart, I’ll skip the app and go to the web site – which is exactly what I find myself doing (frequently deleting the app in the process).

So, from a practical standpoint, here’s my development approach:

  • Need to reach multiple platforms? Do a mobile-first responsive-design web app (that’s how YAWA started). My app must work, completely, on a phone, and must not have a separate “mobile site”, because those always break (and it means maintaining two code bases instead of one).
  • Want device interaction on a solid platform? Carefully launch an app on iOS and keep the feature set 100% in sync with the web app (you *can* cheat and wrap the non-device-interactive features to the web app, but be very careful about your user experience when doing this as it can get you bad reviews really fast – remember, they already can go to your web site).
    • While you’re at it, do a Mac app – with a bit of work you can share most of the code. I recommend keeping all the code in one repository/Xcode project with a different target for the MacOS and iOS versions. Keep the version numbers in sync except, possibly, for minor version numbers if you need to push a bug fix. Oh, and always always include release notes. 😉
  • Need device interaction on more users? Carefully launch an app on Android, again keeping the feature set 100% in sync with the web and iOS apps. I personally haven’t done an Android app as the plethora of devices makes testing and putting out a reliable app more difficult – I’ve stuck with iOS because Apple’s done a pretty good job of making stable development possible.
  • Consider a Universal Windows Platform app (again, keep the feature set in sync before releasing)

You might think “that’s a lot of catch up for the second platform and beyond”. Design your app so that the core functionality is in a RESTful API. The web/iOS/Android/Mac/Windows apps should be clients. Then it’s easy to catch up.

No Release Notes – Take 3

I’ve seen a couple of apps now start adding release notes again. But then, I also saw one company decide to stop adding release notes. My latest procedure, if I can’t delete the app yet, is to write release notes for them in the review.

Here’s my review of one company’s product – “Word”:

Since they don’t include release notes any more, let me tell you what they added in this version:
– Deletes all your files on login
– Spies on your family
– Detects cookie jars in your kitchen and eats all your cookies

If these aren’t the features they added, perhaps they’ll add release notes next time and prove me wrong.

I strongly encourage you to do the same. If they don’t get the hint, at least the reviews will be entertaining.

My Minimalist iPad Pro setup

Keeping a clean slate clean

When I got my new 10.5″ iPad Pro, I, for the first time in years, selected to set it up as a “new device”, instead of restoring from the backup of my old iPad Air 2. This, plus trying it out as a development machine led me to a minimalist organization:

  • I only add apps I need, as I need them, only if I can’t find a better way to do whatever it is that’s driving the desire to install the app
  • Every app goes into a folder named “Stuff” that’s off on the third home screen unless I have a good reason to put it somewhere more visible (i.e. I use it enough that it’s efficient to have it less than a couple taps away)
  • I have one screen for work, one for personal – these are my “areas of focus” in GTD parlance and help psychologically to switch focus. (These areas of focus also have matching folders in OmniFocus, iCloud Drive (personal files), and Box/Google Drive (client/employer files)).
  • I put extremely high-use apps in the dock
  • I aggressively disable notifications

My Screens (“areas of focus”)


Before or after work, I’m on the “personal” screen. Aside from Settings and the App Store, I use it for video watching, texting, and reading. When I “leave work”, I swipe to this screen – feels like I’m leaving the office.


When it’s time to work, I switch to my work screen and start into my daily work checklist (in OmniFocus). I’ve found that on the iPad Pro it’s easy to focus on the task at hand. I had to make some changes to accommodate going from a 3-monitor Mac Pro with lots of toys tools (BBEdit, ExpanDrive, TextExpander, Magnet, Pastebot, Box/Google/OneDrive syncs, etc – I counted about 11 apps I used concurrently) to a single-screen iPad. It’s been an improvement, and spawned a lot of creativity, including a suite of JIRA command-line scripts, learning about mosh, contributing to Blink, re-learning screen and vim, and making better use of my Mac Mini as a server. I took these learnings back to the Mac Pro for improved focus there.


Despite appearances, I have a lot of apps. My iPhone, and old iPad, have an overly-“organized” collection of folders with semi-arbitrary classifications that contain these apps. Since I found myself using Spotlight search rather than thinking “is Google Drive in Business, Productivity, or Lifestyle?”, I created a folder named “Stuff”, and put any app not on the personal screen, work screen, or dock into it.

Putting the “No” in Notifications

You might notice there are no badges in the screenshots. I disallow notifications (including badges) unless the app’s notifications are something by which I really need to be interrupted. Otherwise, checking it goes into my daily checklist and I process it as an “inbox” using the GTD workflow. This includes email. I allow notifications from Messages, HipChat, the App Store, Settings, and Calendar.

The result: better focus

It’s easy to install apps without clutter – drag it into “Stuff”. I can quickly find the apps I use frequently; if I’m bouncing between three apps rapidly (e.g. Safari, Blink, and Box), I’ve found it’s smoother (because it’s more consistent) to hit Command-H and tap than it is to use the app switcher. I only have one thing to look at at a time, so I’m not distracted, and I can use split screen if I really need two things on the screen at once.

Six Reasons Your App Needs Release Notes

Including release notes for your app is good for business – and, more importantly, not including release notes is bad for business. Here’s why:

Release notes improve reviews

People often read reviews to decide whether they will use your app or service.  Several prominent, respected, quality services (including Uber and Dropbox) started to include their release process (“we release updates regularly”) as their release notes.  Their app review scores plummeted to 2 stars (Dropbox) and 1.5 Stars (Uber) on the App Store. Their apps are fine, their service is fine. The ratings plummeted right after they stopped including release notes. Why?

Think about it: Release notes are in the same place in the App Store as reviews, and reviews reset with each update. So, the people who write reviews are largely the same ones that read release notes. You may say, “apps auto-update and nobody reads release notes”. Think again – power users read release notes. No release notes, no reviews (or negative reviews) from your power users. That means your primary source of reviews is people who want to complain about your app or who are less likely to know how to use it.

Dropbox started including release notes again in January – the app’s now up to 2.5 stars; it’s hard to recover lost users.

Release notes build trust

Release notes tell users what you’re doing, and what you’re installing on their device with each update.  “Bug fixes and improvements” is vague but acceptable.  “We release updates regularly” is evasive and insulting.  Of course you release updates regularly, but what are the updates? 

Good release notes communicate to users that you respect them and want to communicate what you’re installing on their devices.

Non-release notes communicate the opposite: you don’t respect them and don’t care if they know what you’re installing on their devices or not.

Interrupting users is a bad user experience

Apps that don’t include release notes tend to announce new features by opening a screen that requires the user to read and/or dismiss it before using the updated app.  When a user runs your app, they’re trying to do something; That is not the right time to share your new features. What is the right time is when they’re reading through their app updates to see what’s new.

Releasing frequently wastes time

A suite of well-known apps states in their release notes, “we release updates weekly”. Why? You’re not releasing anything important enough for release notes, yet it takes the App Store’s reviewer’s time to check your update, it takes user’s bandwidth and time to download the update, and it takes your power users’ time to read “we release updates weekly” every week.

Release notes improve sales

I’m a power user. People ask me for help and recommendations. Apps that have release notes, especially clever ones, I remember and like more than apps that don’t tell me what they’re updating.  (If they don’t tell me what they’re updating, I assume they’re updating something they don’t want me to know about, or that their development process is so sloppy that they just don’t know what’s in each update).  As a result, I’m far more likely to recommend an app with release notes and to inversely recommend against an app that doesn’t have release notes.

Release notes increase user engagement

Power users, if not all users, read release notes periodically.  These all appear in a convenient list in the Updates section of the App Store (on iOS, not sure about Android).  If users read something interesting in the release notes from an app they haven’t used or have forgotten about, they may open the app to see what’s new.

Conversely, as I’ve written about before, users are likely to delete an app if they’re not using it extensively and see vague statements like “we update our app regularly” as the release notes.