Beyond Objective-C, Beyond Swift

I had been writing software for less than a year when Apple introduced Automated Reference Counting (ARC) in iOS 4. Even in that short span of months I had struggled often enough with manual memory management (retain/release) that I immediately grasped the significance of ARC. I’ll never forget the figure that accompanied the transition guide documentation:

It perfectly illustrated the benefits of ARC. ARC didn’t make code shorter through syntax niceties or compacted expressions. It obliterated whole swaths of code throughout a project. An entire layer of error-prone state management was reduced to an almost invisible implementation detail.

ARC seemed too good to be true. Granted, to this day there are still some areas where memory management requires finessing, but for the most part it is quite close to magic — especially for anyone who remembers what it was like to write iOS software before ARC.

Progress is Offensive

During the first few years after the ARC introduction, mastery of old-fashioned manual reference counting was a point of pride among seasoned developers. Using ARC was somehow not “real” Objective-C programming. The kids these days and their ARC. That attitude is one that I don’t encounter much anymore. By the time Apple transitioned OS X to ARC, the stigma had all but disappeared.

Advances in software development are offensive to the practitioners of the technologies made obsolete. The new technology seems childishly simple in comparison to the complexity of what it replaces. At the risk of overgeneralizing, I think this reaction is natural. When you’re passionate about your work, you tend to fall in love with its idiosyncrasies, even those that might actually be burdensome.

Software development advances via abstraction. Best practices from lower levels of infrastructure are codified, automated, and optimized for common scenarios. It’s this abstraction and simplification that is the source of offense for the champions of older ways of working. When it’s done right, a new technology automatically handles tasks which previously required significant planning and effort. No one wants to see their expertise made obsolete — until they realize that the new layer of abstraction they thought was childishly simple is actually the building blocks for new complex things they’d never have been able to build with the old tools.

That’s what I want from an Objective-C replacement, but it isn’t what we get from Swift.

A Feeling of Disappointment

Some people are huge fans of Swift already. Others are ambivalent, doubtful, or outright opposed. I would place myself among those in the ambivalent group. I haven’t been able to articulate my thoughts and feelings yet. I think I can now.

There’s a lot to like about Swift. I especially love enums, string handling, the Playground REPL. Swift has clearly been designed with thoughtfulness and care. But nevertheless I can’t shake a feeling of disappointment. The best way I can sum it up is:

Swift solves problems that I don’t really have, and the problems I care about most Swift doesn’t solve.

Let’s use Apple’s Swift landing page as the canonical reference for the reason Swift was made. Here are the Swift features that Apple lists first (not including features that Objective-C had already, more or less, like automatic memory management):

These are all demonstrable improvements over Objective-C. Let’s set aside the tired debates about the merits of generics, inferred types, functional programming patterns, etc. and agree that yes, Swift is better at many things than Objective-C.

So why am I disappointed? My disappointment with Swift is because all the items in the list above are only iterative improvements. None of them address the biggest challenges I face as a developer. To explain why, let me first describe the way I work. Then I’ll return back to Swift.

How I Work: Coding in the Air

I build all my software in a manner I call coding in the air. It began as a fruitful working relationship with Jamin Guy, my colleague at Streamweaver and Riposte. We would sit in Jamin’s living room and discuss architecture at length. Sometimes sessions would last for five or six hours. Neither of us would be touching a keyboard. We’d build up and tear down APIs in our minds, rattling off class names, property lists and method signatures over and over, each time a little different. Our mouths were sore from repeating the same words. Gradually the right patterns revealed themselves.

At the end of these sessions, the implementations were so clear in our minds that the actual work of writing software was not much more than typing.

It takes enormous amounts of concentration to build software in this way, but it’s worth it — especially if you have the benefit of a like-minded partner. Other than an uninterrupted block of time, there’s virtually no cost to coding in the air. As soon as an idea doesn’t work, it vanishes. There’s no code to rewrite or files to delete.

Coding in the air shifts your focus away from implementation details and onto architecture. It’s architecture that is the hardest and most important part of any project. It’s the part that takes the most time to implement — and the most time to reimplement should you paint yourself into a corner with a bad assumption early on. Coding in the air reduces the risk that you’ll need to reimplement something.

Implementation is the Bottleneck

When at last the time comes to fire up Xcode, the implementations are fairly clear in my mind. But this is where my problems really begin. Every project I’ve worked on involves rewriting the same kinds of implementations, but this code isn’t re-usable. Things like:

These are just some of the time-consuming tasks we all face when writing Objective-C applications. They take a long time to do well, and involve a great deal of repetitious, brute-force work. These tasks deplete limited resources. Developer time is the biggest expense subtracted against a startup’s bottom line. It’s also mentally and physically taxing. It’s hard to stay focused on the core problem that matters most: building something that users love.

Back to Swift

Swift doesn’t reduce the time and energy it costs to implement the boilerplate goo that comprises our applications. Even factoring out the learning curve (which is steep), Swift merely shifts the locus of debugging from runtime into compile time. It solves some common implementation mistakes with Objective-C, but it doesn’t make whole applications faster to implement. Saying Swift makes programming easier is like saying that iOS 8 extensions make it easier to use an iPad the way that Federico Viticci does — more straightforward, perhaps, but as a workflow it’s just as complex.

The net result will be this: Objective-C developers will spend the next several years transitioning to the new syntax and assumptions in Swift. When that transition is finished we will likely still be where we left off in 2014. We’ll still be spending long hours writing boring, buggy, non-reusable implementations of persistence, networking, trigger/response, and layout code.

What I Want

On a continuum from the abacus to punch cards to Objective-C, Swift is only an iterative improvement upon Objective-C. Perhaps someday Swift will serve as the underlying language behind the kinds of solutions I’d like to see. Regardless of how it happens, here’s some of the things that I want:

I want whatever comes after Objective-C to obviate whole layers of architecture the same way that ARC made memory management a concern of the past. I understand that what I’m asking for is more than just a programming language. But that’s because the biggest obstacles holding back Objective-C development can’t be solved by a language alone. We need a new paradigm.

|  25 Sep 2014




The iPhone 6 Plus Makes Designing Apps for Physical Comfort More Difficult — and More Important — Than Ever

Several months ago I wrote a post about the ingredients that make an app feel comfortable. This post is more applicable now than ever.

I’ve spent only a few days with an iPhone 6 Plus and it’s clear that the designs of many popular iOS apps are inappropriate for a display this large. It may be a huge phone, but the iPhone 6 Plus is still a phone. You should be able to comfortably perform common actions in your favorite apps with just one thumb.

I absolutely love the huge display. Five and a half diagonal inches are better for many things: web browsing, reading RSS, watching movies, and more. It’s misguided to suggest that the size of the display is what needs to change. The problems are caused by the misuse of interface elements that were designed to fit constraints imposed by smaller displays.

These are just two of many problems the new devices have introduced. My experience is with a 6 Plus, but I have long fingers. From what I have read, people with small or average sized hands have similar complaints about the iPhone 6 (non-plus).

Solutions to these design problems are waiting to be found, but they will not be obvious. What I know for sure is: we can do better.

  1. There’s a heuristic in Unread that favors vertical scrolling over horizontal panning. I don’t remember the exact ratio (It wasn’t 50/50. I tried many ratios until it felt right). Most of the time you’re just trying to scroll through a list of stuff. But when a dismissal is determined to be the user’s likely intention, the dismissal pan gesture overrides all other panning gestures. The result is buttery, responsive navigation. ↩

|  23 Sep 2014




Iterate 74: Designing for iPhone 6 and Apple Watch, with Kawano, Sinclair, and Wiskus

I was a guest on last week’s episode of the Iterate podcast. There was so much to talk about after Apple’s announcements. My biggest concern: I’m worried that many apps won’t figure out how to feel physically comfortable on iPhone 6 and 6 Plus. My biggest point of excitement: I can’t wait to see what people do with the Apple Watch, especially for customers who can’t use their iPhones while they work.

|  18 Sep 2014




Good Design is a Process, iPhones 6 Edition

From John Gruber’s review of the iPhones 6 (emphasis added):

My understanding, talking to people at the event last week, is that Apple’s industrial design team mocked up prototypes of every single size between 4.0 and 6.0 inches, in tenths-of-an-inch increments, and from those 20 sizes selected the two that best hit the sweet spots for “regular iPhone” and “ginormous iPhone”.

Two takeaways with regards to my post yesterday about healthy design processes:

|  17 Sep 2014




Good Design is About Process, not Product

A designer’s process determines the difference between mediocre and great work. Natural talent and training aren’t substitutes for good design habits. The right process can cover many shortcomings of talent and skill — but the opposite is never true. A good process will bring out your best and most unique work. A bad process will leave you with tired, unsurprising clichés.

The easiest way to develop a healthy design process is to copy the good habits of designers whom you admire. In this post I’ll share practical suggestions that I’ve borrowed from my favorite designers — and from a few bright thinkers.

This post ended up much longer than I had anticipated. It could probably be broken up into many smaller posts, but I think it’s important to see all these lessons together, to emphasize the accidental nature of their origin. Great advice seldom arrives when you’re expecting it.

TL;DR

The list below is the short version of what I’ve learned. These aren’t fluffy aphorisms to comfort you on a rainy day. Brace yourself for these as if they were cold water splashed on your face. If you take them seriously, they will reshape the way you work, whether solo or as a team.

Dumpster Diving

You Won’t Believe These Three Simple Steps to Being a Great Designer is not the title of this post. If only being a great designer was that simple. Isn’t everyone tempted to calm the fear of failure with the comfort of a checklist?

When I look at a design that inspires me, I try to imagine myself making it. Many times I have emerged from that exercise of imagination empty-handed. I couldn’t figure out how other designers were making such great work. I felt disheartened, as if they were guardians of a secret knowledge that I wasn’t allowed to have.

It was a long time before I realized that I was solving the problem in the wrong direction. I was beginning with the inspiring result and trying to work my way upstream to the origin of a design. When I looked at the history of a project from a backwards vantage point, every decision seemed obvious. I didn’t see the twists, turns, and dead ends that didn’t make it into the final product. But when I changed perspectives and started studying processes, these paths became clear.

If you want to learn design, look in a good designer’s wastebasket.

When you study another designer’s trash, you will uncover the processes that drive her work. How many iterations of an unused idea were made before that idea was finally thrown away? How much variety can you find in the attempts at solving a particular problem? What common traits kept popping up between revisions? Leonard Cohen wrote, “Poetry is just the evidence of life. If your life is burning well, poetry is just the ash.” The tangible results of all creative acts are just the ash left behind by the way we work.

Healthy Design Processes

What makes a design process healthy? I have some practical answers to this question. What I have to share comes from a variety of sources. These are in no particular order:

Let’s look at each one of these in detail.

1. Process, not Product

I am continually inspired by a little book called Zen in the Martial Arts by Joe Hyams. Hyams was a journalist who developed a late-blooming passion for martial arts. His book has little to do with either Zen or the martial arts, except incidentally. The real joy of the book is the copious practical wisdom it has to offer.

What follows is one of my favorite chapters, reprinted in full (emphasis added), about how focusing on process and not the end product can paradoxically help you succeed at both:

Master Bong Soo Han is a Korean of medium height with a full head of iron-gray hair. There is quiet authority in everything he says and does. No movement or word is superfluous. He is the traditional martial artist who learned hapkido from his master in Korea who, in turn, learned it from a master who had been taught by a long, continuous line of other masters. A session with Master Han is not just a workout, it is also a lesson in life. I always feel enriched after leaving his dojang.

I was fifty years old when I started the study of hapkido with Master Han. From the beginning the learning process was slow and often difficult for me because hapkido requires an extremely limber body. My body had stiffened with age and I had back problems that threw me off balance and made every kick above waist level painful. My learning was further complicated by the presence of much younger men who were able to do easily that which required tremendous effort and concentration on my part. There were many times when I considered quitting, a fact Master Han recognized.

One afternoon following a workout, Master Han invited me to have tea with him. After he had served the tea, he began, “You will never learn to do any endeavor properly unless you are willing to give yourself time. I think you are accustomed to having everything come easily to you, but this is not the way of life or of the martial arts.”

“I am patient,” I said.

“We are not talking now about patience,” he answered. “To be patient is to have the capacity of calm endurance. To give yourself time is to actively work toward a goal without setting a limit on how long you will work.”

He had touched the core of my problem. I had given myself a set amount of time to become reasonably proficient in his style, and I was frustrating myself because I didn’t seem to be achieving the goal quickly enough. When I eliminated the deadline from my mind it was like removing a weight from my body. Within a few months I was able to perform with the rest of the class.

Equally important, I used Master Han’s advice to resolve an immediate problem. I was working on a book at that time, and the writing was going slowly. That frustrated me because I had agreed to start another project in short order and it was weighing on my mind. Now I could see that my focus was wrong. I was doing the same thing I had done with hapkido. I should have been concerned with the process of working on the book rather than on its completion. Once I removed the time constraint from my mind and approached the book without an arbitrary limit, I was able to dedicate myself to the writing and work without anxiety.

Hyams was a writer, not a designer, but I think his advice applies equally to all forms of creative work.

2. Open vs. Closed

In 1991, John Cleese delivered a lecture on creativity to an audience of delighted Norwegians. This obscure lecture has been a life-changing discovery for me. It is only 36 minutes long, yet it rewards many re-watchings. For the sake of brevity I’ll summarize his points as succinctly as I can.

Creativity is a way of operating, a habit of the mind — not a talent. When you grasp this fact, it becomes painfully clear that the way we organize our time and our interactions with colleagues often undermines the very creativity we’re supposedly chasing after.

Creative sessions should be kept formally separate from the hurried mundanity of getting things done. When we need to solve a problem that requires creativity, we should deliberately shut out all of that noise and stress. For a clearly-defined interval of time — Cleese suggests an hour and a half — we enter a state of humorous, open-ended play. Within this cocoon of play, we strive to think of as many ways to view a problem as we can muster.

The point is not to solve the problem (though that will eventually happen), but merely to explore it. The urge to find a decision and pass judgement will destroy the fragile creative process. Instead, postpone judgement until the allotted time for creative work has lapsed. Only then should you return to a “closed” mode, in which you are judging and implementing the plans that your creativity has inspired. Repeat the cycle of open and closed modes with regularity.

My summary of Cleese’s lecture is a weak paraphrase at best. You really ought to do yourself the favor of watching the entire video. It’s rife with his characteristic wit. Prepare to laugh and be cheerful.

3. Be Indecisive

Marc Edwards, a knowledgeable designer and a founder of Bjango, recently posted a moving article about his memories of a former boss, a design director at a graphic design firm.

Marc recalls how he at first misjudged his boss as being flaky and indecisive. Marc later learned that there was a career-defining lesson hidden in his boss’ madness:

To me, he didn’t appear to know what he was doing. He’d fumble around, eventually landing on something that may or may not be final. It was ok, but not great. Then he’d ask for more changes. Changes that were obviously bad.

[…]

Then it clicked.

He’d intentionally try different and crazy things, knowing that most wouldn’t work. He didn’t care. He didn’t care and it didn’t matter — we’d end up in places we never would have if we over thought the layout. The question wasn’t “what is the best way?”, but “what are the many ways?”, deferring judgement until the last possible moment. Judgement may feel good, but it has no value. The value is in the outcome.

And the outcome was often solid, stunning designs that were unconventional. Non-obvious solutions. From the outside and to other art directors, it appeared magical. But, from within the process, far less nuanced and intentional.

It was also playful — the exploration was fun. Quickly throwing many alternatives together established a rhythm. It meant no one was invested in any particular direction. It also meant we never had designer’s block, because we allowed ourselves to create bad layouts, knowing it may be a bridge to a better solution.

I especially loved Marc’s last observation about how his boss’ methods prevented designer’s block. In retrospect, I can see now that whenever I have experienced designer’s block it has been out of a premature urge to make a decision and alleviate the discomfort of a not-yet-solved problem.

4. Intervals, not Deadlines

Aza Raskin, an accomplished designer who is now a VP at Jawbone, wrote a blog post in which he recounts the fascinating insight that led Paul MacCready to build the first human-powered vehicle capable of crossing the English Channel.

In 1959, a wealthy British magnate named Henry Kremer offered a cash prize (equivalent to $2.5 million in today’s dollars) to the first team who flew across the English Channel using only human power. Eighteen years passed by before MacReady won the prize. Many had tried and failed.

MacReady’s fundamental insight was that those who had come before him misunderstood the nature of the problem to be solved. All the previous teams spent many months designing and building their planes. Most would crash after a few minutes or even seconds, requiring a lengthy period of recalculation and rebuilding. MacReady saw things differently:

The problem was the problem. Paul realized that what we needed to be solved was not, in fact, human powered flight. That was a red-herring. The problem was the process itself, and along with it the blind pursuit of a goal without a deeper understanding how to tackle deeply difficult challenges. He came up with a new problem that he set out to solve: how can you build a plane that could be rebuilt in hours not months. And he did. He built a plane with Mylar, aluminum tubing, and wire.

The first airplane didn’t work. It was too flimsy. But, because the problem he set out to solve was creating a plane he could fix in hours, he was able to quickly iterate. Sometimes he would fly three or four different planes in a single day. The rebuild, retest, relearn cycle went from months and years to hours and days.

MacReady’s insight is especially applicable to software design. If your team is comprised of multiple designers and developers, you are probably familiar with the tendency for long delays — days or weeks — between a new internal build and some design feedback, or between that feedback and a revised build. Such delays are a serious problem. It makes it hard for engineers and designers to keep finicky implementation details fresh in their minds.

Every speed improvement counts. Companies like Flipboard and Facebook use automated beta deployments and in-app design tweaks to eliminate mundane tasks like manual deployments and updating hard-coded user interface constants. Live preview apps like Skala or Flinto make it possible to preview a design directly on your device with as little overhead as possible. When you focus on shortening the turnaround time between each iteration of a design, you’re freeing your team to collaborate more efficiently and to deliver their best work.

5. Redesign is the Essence of Design

In his book On Writing Well, William Zinsser makes an eloquent case for the importance of rewriting:

Rewriting is the essence of writing well: it’s where the game is won or lost. That idea is hard to accept. We all have an emotional equity in our first draft; we can’t believe that it wasn’t born perfect. But the odds are close to 100 percent that it wasn’t. Most writers don’t initially say what they want to say, or say it as well as they could. The newly hatched sentence almost always has something wrong with it. It’s not clear. It’s not logical. It’s verbose. It’s clunky. It’s pretentious. It’s boring. It’s full of clutter. […] The point is that clear writing is the result of a lot of tinkering.

I would argue that redesign is the essence of design. No one, no matter how talented, lands on the best version of her work in the first attempt. Shipping a first or second draft is wishful thinking at best, if not outright laziness. There is always some room for improvement: something new to add, an excess to remove, things to rearrange. New ideas often spring upon us when we least expect them. If you’re in a state of perpetual readiness, you can respond to new ideas without having to fight the inertia that wants you to accept average work.

6. Opinionated Principles, Liberal Implementations

There’s a common refrain among certain software design circles:

Make opinionated software.

The idea is, as the 37 Signals writer puts it:

The best software has a vision. The best software takes sides. When someone uses software, they’re not just looking for features, they’re looking for an approach. They’re looking for a vision. Decide what your vision is and run with it.

I think this is valuable advice, but only when it’s understood in a helpful way. I have seen it used to justify the brash ego of designers who refuse to compromise on minor matters.1 Good opinionated design has little to do with personal taste. It’s about building a firm foundation for your project out of a handful of guiding principles.

Good design is opinionated in its principles, yet liberal in their implementation. The best example of this is the iMac.

There have been many iMacs over the last decade and a half, each one different from the previous — sometimes dramatically different. Yet each one has been unmistakably an iMac. This is because each version was a interpretation of a few unchanging principles:

Apple’s hardware designers allowed themselves the freedom to express these principles in as many ways as they could imagine, yet they never allowed themselves to question the underlying principles behind every iMac. This is the essence of opinionated design.

When you’re embarking on a new project, or on the redesign of an existing project, before you do anything else you need to find your principles. Don’t open Photoshop or Xcode until you have studied the problem you wish to solve and can describe how you want your solution to feel. Distill those thoughts into a handful of principles. Write them down. Memorize them. Make a poster out of them.

Your principles will give you clarity and objectivity when solving hard implementation problems. Without principles, the only objectivity is the person with the loudest voice in the room. Every decision should be weighed against your guiding principles. This is how the best ideas win.

  1. I know I have certainly been guilty of this. ↩

|  16 Sep 2014