Addicted To Threes

While the rest of the world frets about the loss of Flappy Bird, some of us have become unexpectedly dependent upon a dazzling numerical puzzle game from Sirvo LLC called Threes.

I learned about the game through my friend Marco Arment, who gave a ringing endorsement of the game when he said it “doesn’t suck.” He’s right, in many, many ways. I was moved by his assessment to download and play the game. I’m glad I did, and I’m also devastated that I did.

It turns out Threes is a better game than I quite know how to comprehend. I want to play it again, and again, and again. It’s dangerous.

What is the secret sauce of Threes, and games like it? I’m not sure, but I have some impressions. If I were designing a game and I wanted to hope for anything near the irresistibility of Threes, these are the lessons I’d be taking from it:

  1. It’s easy to learn. The game has a brilliant interactive training mode that guides you through the simple rules that govern the game. Even a game with simple rules will be put aside if it takes more than a minute or two to learn, so luring folks in with a tutorial is a good call.
  2. It’s easy to “do well”. From the moment you start playing Threes you will find yourself making immediate, almost constant progress. The format of the game has smaller number tiles combining with one another from the very start, giving a fast-paced sense of progress that should thrill even novice players.
  3. It’s much harder to “do really well”. Once you’re hooked, you’ll find yourself trying to figure out what it was about your choices in one game that made you do so much better than you did in another game. And if, like me, you’re not some kind of cosmic genius, you’ll be intrigued to figure out what that is. I’ve been balancing my play between “having a good time” and “struggling to understand.” Sometimes the two do overlap. I’ve developed some techniques that seem to be effective, but on the whole I recognize there is a lot of room to grow. There is a lot to understand.
  4. It’s easy to get a reality check. Here’s a real kicker. If i were playing Threes in the privacy of my home without the benefit of Apple’s Game Center to let me know just how well my proud accomplishments stack up to friends and strangers, I’d be feeling pretty good. There’s even a chance that, without the knowledge of just how well other people are doing, I might reach a point where I convinced myself I had the game figured out. A quick glance at the high scores of my friends lets me know that I’ve figured out how to be relatively competent at the game (current high score: 9,132), but nowhere near as lucky and/or skilled as some friends and many strangers.

I’m sure these four points are the tip of the iceberg, but they are what stand out to me. Of course, it doesn’t hurt that the game is well-designed and adopts an honest business model (no ads or scammy upsells). The target audience for Threes is probably dramatically smaller than the audience of Flappy Bird, but especially for nerds or folks who just love a good numerical puzzle, Threes is a great value and an example of how great iOS games can be.

Can’t Take That Away

I was surprised how much I enjoyed all the pro-Mac celebration today, marking the 30th anniversary of its debut.

Apple’s home page is dedicated to the Mac, and links to an extremely extensive special feature outlining, year-by-year, some significant uses of the Mac, by significant people, as well as the major shifts in design and functionality that the computer has seen.

As a long-time Mac user and developer — I started working for Apple at 18, went indie at 26, and am 38 now, still working on Macs — I was touched by the amount of pride Apple exudes today in celebrating the triumph of the Mac. Especially over the the past several years, as many people have shifted their attention to mobile devices based on iOS and Android, it’s easy to forget that the Mac is still an amazing device and that the hardware and software both continue to improve every year.

Topping off a great day, news came out of Cupertino that Apple has posted giant posters on campus, upon which are printed the names of “every employee who has ever worked for Apple.” Holy cow, my pride overflows. What a grand, yet humble gesture. My old friend Dan Curtis Johnson confirmed that I had made the cut:

In close proximity, both Dan Jalkut and Ellen Hancock. Such a faraway time, the long-long ago.

It was long-enough ago, that some people still called me Dan.

I learned so much at Apple, and had many profound experiences that shaped the way I see the world both technically and otherwise. I was hired a year or two before Steve Jobs came back, and one of my first joys at Apple was adding my own name to the “About Box” for the Memory Control, which I had taken charge of. And because I could, I also added the names of some friends. I was a little immature. When Steve came back, one of his company-wide edicts was that the names of individuals must be removed from about boxes. I had to commit the source code that wiped my own identity off the faces of the products I had worked on.

Steve’s explanation was something along the lines that it was unfair to put the names of a few in about boxes because it was a disservice to all the other employees who were not listed. He insisted that each of them was as important to the success of the company as the people who were listed. Of course he was right, but it didn’t feel great at the time.

It’s hard not to think of Steve when I read about this perfect gesture of gratitude to all the employees who helped, directly or indirectly, in making the Mac a success. The Mac is his baby, and it’s grown to be not only strong and robust, but in some respects unassailable, thanks to the hard work of the tens of thousands of people whose names are on those posters.

I started at Apple while I was still in college, barely having glimpsed the professional world outside of the company. I learned a lot in school, but I learned much, much more at Apple. My time there completely shaped not only the way I develop software but the reasons I develop software. Fundamentally: to serve and delight the people who use it.

I often think back wistfully, wondering what would have happened if I stayed at the company. I might have gone on to do important, admirable work, or I might have become one of those (rare) old slackers at Apple who doesn’t earn his or her keep. Either way, my name would have been on one of those posters today. And either way, it would have been well-earned. People often say the great thing about education is that nobody can take it away from you. The same is true of working for Apple, and the company’s gestures today strongly underscore that fact.

A Billion Dollars Worth Of Work

John Gruber shared a link about Facebook’s Sheryl Sandberg and her new “billionaire” status. He cites Bloomberg’s David de Jong quoting author David Kirkpatrick: “Did she do a billion dollars worth of work?”

I thought Gruber’s criticism of the statement was fair, and thought-provoking:

Would Kirkpatrick have asked this of a man? And if he had, would Bloomberg have run the quote?

It’s probably true that women such as Sandberg are subjected to a greater, unfair amount of speculation regarding the appropriateness of the rewards for their work.

In my opinion, that’s how Gruber’s link should have ended. But he added:

I searched Google for the phrase “Did he do a billion dollars worth of work?” and the only hit was this tweet from Jezebel editor-in-chief Jessica Coen, retweeting this tweet from Alex Leo pointing out the absurd gender bias in this article.

The implication, by my reading, is that the lack of Google results for the searched phrase: “did he do a billion dollars worth of work?” is evidence of a gender bias against women who have earned a billion dollars.

My problem with this line of reasoning is that the naturally contrasting search: “did she do a billion dollars worth of work?” also yields nearly no results. The vast majority, if not all of the results for that search are related to news from the past day related to this issue.

I don’t doubt that people are more critical and dismissive of a woman who has earned herself a billion dollars, but Gruber’s search example doesn’t support the claim. I wonder if there is a search that would support the claim? On Twitter, Gruber pointed out that there are fewer female than male billionaires. So perhaps it’s insufficient to measure disdain for female earnings by searching on the scale of billions? A paraphrased search on the scale of millions yields zero results, and zero for men as well. So “nobody” is complaining about the worthiness of folks, male or female, who earn a million dollars.

I agree with Gruber’s premise, but his own evidence doesn’t support it. I would rather see flimsy evidence omitted from an argument I agree with, because it offers a weakness for naysayers to attack.

Alex Serriere, on Twitter, offers a simplified search that does support Gruber’s premise, albeit indirectly:

@danielpunkass @gruber I think these searches sort of prove the point: “did he do enough” 347k results, “did she do enough” 1.9m results.

Of course I concede that none of this is scientific, but as far as off-the-cuff Google searches go, I find Alex’s results far more compelling and supportive of the argument at hand.

Restart Your Day Job

This timing could not be more perfect. As Matt Gemmell exits the professional software business, my old friend Duncan Davidson returns to it. For the first time in many years, he’s taken a full-time job as a software engineer, working for Wunderlist.

Duncan has a rich history in software development. From his time at Sun, he is the man behind Apache Tomcat and Ant, two Java tools that even I, a person who is mostly oblivious to Java, am familiar with. (As it turns out, I even use Ant in the build process for MarsEdit. That’s a story for another day.) Duncan also made a name for himself within the Cocoa community by writing one of the earliest Cocoa development guidebooks.

But Duncan is also a photographer, and a damned good one at that. I was impressed when, years ago, he put his considerable software abilities aside to focus on that lifelong passion. My first memories of this shift are seeing him roam the halls of Apple’s WWDC conference, not as an attendee but as a paid professional photographer. He went on to photograph for various O’Reilly Media conferences, and to this day he is the the main stage photographer for the illustrious TED Conference.

That’s an important detail to note in Duncan’s story: by returning his focus to the craft of software engineering, he will not be giving up his passion for photography. Professionally, he will continue to work with TED, and privately, I’ll be damned if you ever find him without a camera at close hand.

Duncan had the guts, many years ago, to give up software engineering to pursue photography. That has worked out very well for him. Now, he’s showing he has also has the guts to return to what he left behind. As a “new developer” in 2014, I’m sure there are things for him to learn from his teammates at Wunderlist. But I’m also sure there are many things for him to teach. I look forward to seeing where Duncan’s passions for software and photography take him next.

Quit Your Day Job

My friend Matt Gemmell has long been known as a prolific Mac developer, public speaker, and selfless contributor of open source code to the Mac community. He’s also a writer. He’s shared his thoughts on subjects ranging from coding well to living well, and in a recent post he makes the broad proclamation that he will give up the profession of programming to become a full-time writer. Making Changes:

Maybe it’s foolish, and from a commercial point of view it certainly looks that way, but I must try. As of this moment, I’m no longer developing software, either for myself or for others. I’m writing full-time.

Folks who read about this daring change of course will likely have one of two reactions: to support him unconditionally, or to condemn him as a fool. Count me among the supporters.

Most people who mutter the disgusting, deplorable phrase: “don’t quit your day job,” do so from a position of ignorance, of envy, or of both. “Quitting one’s day job,” so to speak, is the starting point for any major change in one’s career, and most of us could stand to do a lot more quitting and a lot less settling.

Sometimes I wonder what would happen if I quit my career of programming and threw all my energy into being a professional musician, interface designer, or … who knows what? I am at once afraid I would be an utter failure in another field, and worried that I might miss my beloved programming too much. But that’s not to say the day won’t come when I lay down my IDE and move on to another life pursuit.

Congratulations to Matt on making a difficult, important decision. Best of luck to him in his new career as a writer.

Apple’s Nest

Google is acquiring Nest Labs, and since the news broke, most of the analysis I’ve seen has to do with why Nest might be worth $3 Billion to Google, and whether or not it’s a blow to Apple that Google bought the company before they could.

I agree with the folks who point out that $3 Billion is a hefty price tag for a small company that only sells home thermostats and smoke detectors. But I also agree with the folks who argue that the potential upside for Google could be huge. On the latest episode of The Talk Show, John Gruber and John Moltz cover many potential wins for Google: a proven consumer product expert in Tony Fadell, tens if not hundreds of talented engineers, and perhaps most importantly a team with a knack for delivering casual infometric devices to the masses.

For years, Google’s successful tack has been first inserting itself between users and their data, and then figuring how to best capitalize on that relationship. This approach pans out proportionally to the total number of users and to the amount and diversity of data being intermediated. As Google’s knowledge of people and their data grows, it empowers them to provide increasingly clever life solutions. It also empowers them to help themselves to what advertisers will pay for access to this very large, very well understood user base.

The products might seem to offer little to Google, but it’s easy to imagine how Nest’s knowledge could strengthen Google’s other services. For Maps? “Raise the thermostat in my home to 68F when I am 1 mile away from arriving at home.” Or for Gmail and Google Voice? “Do not disturb … unless there is an emergency at home.” It also seems reasonable to assume that Nest’s two shipping products are the tip of the iceberg and that Tony Fadell and his team have a long list of ideas for how their product line should expand in the future.

What does it mean for Apple that Google acquired Nest? Not much. Unlike Google, Apple has made a habit of staying out of the relationship between users and their data. Sometimes to a fault! For most of Apple’s products, knowing anything about the specific data that users are working with is at best an afterthought and more often a degree of involvement that the company has made a point of avoiding. What are your emails about? Apple doesn’t want to know. What kind of writing are you doing in Pages? Not interested. What are your favorite mapping POIs? They barely know where anything is, let alone whether you’ve been there or not. This is Apple’s flaw and it’s great, great asset: they care much, much more about the kinds of things than the specific things that people use their products to work with. Google is more interested in raw, specific data, while Apple is more obsessed with generalized ideas about data.

On that point, one reason I wouldn’t expect Apple to acquire a company like Nest is that the products are far too specific, far too niche. Apple doesn’t make very many specific things anymore. They make general tools and leave it to customers how they should best be used. In fact, over the past 10 to 15 years, Apple’s products are increasingly generalized, and more suitable to a wide range of uses (and customers) as the products become more refined.

Apple used to sell a countless variety of Mac models which are now more or less reduced to MacBooks, iMacs, Mac Minis, and the Mac Pro. Apple used to sell iPods for playing music, QuickTakes for taking pictures, and printers for … printing. Now they sell devices that double as music players, devices that double as cameras, and devices that extend the capabilities of 3rd party printers.

Apple’s Airport Express could be sold as a standalone Wi-Fi printer adaptor. Have a USB-based printer? Just plug it in to the Apple AirPrinter device and now it’s a Wi-Fi-connected printer. It could also be sold as a Wi-Fi music adaptor. Have a pair of powered speakers? Just plug it in to the Apple AirPlayer and let your tunes fly. But no, it’s sold as a Wi-Fi base station. A base station that happens to offer many features that are generally useful to a household with network-connectable devices.

In many respects Apple’s Airport Express is like Nest’s thermostat: a small form factor with built-in WiFi and considerable smarts. Wouldn’t it be interesting if the next version of the Airport Express featured a touch screen for interaction and feedback? During AirPlay broadcast of music to connected speakers the on-board display could show the album artwork, artist, and song title, as well as a convenient UI for skipping or favoriting a song. While printing documents it would reflect up-to-the-moment job status and offer a big, fat “Stop” button for canceling an unnecessary printout. And when it wasn’t doing anything in particular? It could show generally helpful information such as the current time, local weather, etc.

Given Apple’s history of expanding the functionality of the Airport Express, I wouldn’t outright reject the possibility that they might add a temperature sensor or smoke detector to the device itself. Or better yet, what if they announced a standard Bluetooth LE protocol for in-home instruments from any manufacturer to integrate seamlessly with Apple’s $99 Airport Express? That would be pretty great, and maybe at that point it would finally be time to come up with a better name for Apple’s Nest.

Letterpress Rules

My friend Brent Simmons shared his personal rules for the popular competitive word-forming game, Letterpress.

In a nutshell Brent’s rules are to always pass the first turn after a victory, and to avoid playing suffix or prefix variations of an opponent’s last word.

I strongly agree with passing the first turn after victory. The first play offers a strong advantage in the game and if you rematch in victory and play the first word then you give yourself an unsportsmanlike advantage.

The second rule however is too fiddly for my taste. I feel that there would be too little overlap in agreement on rules for this to be reasonably expected to be adhered to. It was actually my initial objection to the game when I first played it over a year ago. I agreed with Brent’s sentiment but thought the game itself should somehow enforce it. Since then I have learned to be at peace with the fact that if I play “BEMUSED,” I had better be prepared for my opponent to play “MUSED” if it suits her.

I have found however that there can be an impedance mismatch when an opponent has dramatically different “rules” of his own. For example I once played an excruciatingly long game with somebody. I was having a good time, and struggling to win. After 30 or 40 turns of what I saw as “end game,” he sent me a message on Twitter along the lines “Do you think I should end this thing?” What?! Of course you should end this thing. It’s a competitive game! But it turned out that one of his objectives was to string games along whenever possible.

Not surprisingly, because I’m kind of a stickler for rules, I have a few to add to Brent’s. I don’t expect my opponents to necessarily adhere to them, but I find them to be the most sportsmanlike way of playing the game:

  • First, to repeat Brent’s advice: Always pass the first turn when rematching after a victory.
  • No word reference or other “cheats.” I don’t view trying every damned word combination to see if it flies to be cheating, but using an automated tool is not cool. The germ of forming the words you play should come from within your own head.
  • Bogus words are fine, as long as Letterpress accepts them. I’ve played bad enough words that I’ve apologized to my opponent, but the game is the game. It is assumed that all players will play “bogus” words when advantageous, so roll with it.
  • Always win with the smallest advantage possible. A perfect game of Letterpress for me is a 13-12 victory. Because there are no advantages to a huge victory, apart from gloating or possibly making an opponent feel inferior, the goal of the game for me is to win, but to win graciously. Sometimes I go to a little extra work to find a low-enough scoring word that still puts me over the top. (When I’m lucky enough to win, that is!)

Choices And Consequences

Apple’s iOS and Mac App Stores employ a crude system of ratings and reviews that nonetheless has an impact on how marketable an app is, and accordingly, how much money it brings in.

Since very early in the history of these stores, developers looking to raise the average “star rating” on their apps, and to garner gushing words of praise in their reviews, have dealt with a conundrum: users do not typically review apps unless angered or … encouraged.

So developers have encouraged users to review their apps, using techniques that span a spectrum from what most users would consider harmless, to tactics that even the most naive users recognize as badgering, condescending, and manipulative.

At the harmless end of the spectrum, you find gentle reminders on Twitter, links in the about boxes of apps, and earnest pleas in the signature footer of email correspondence. These are not a huge deal to most people, and are usually phrased in a way that extracts empathy and a sense of obligation from passionate users: “We know it takes time and effort to review an app, but if you value our work please consider leaving a positive review. It means a lot. Thank you!”

At the other end, you find blatant harassment and tricky language meant to confuse users into capitulating. Modal alert panels might interrupt a user’s workflow at inopportune times, demanding that they either leave a review now or be reminded later to do so. The natural reaction of any user in this situation would be to try to determine which series of hoops must be jumped through to get the app to leave one friggin’ alone!

Recently John Gruber addressed the problem of apps on the badgering end of the spectrum, and merely hinted at a grass-roots campaign that might make a dent in the problem:

I’ve long considered a public campaign against this particular practice, wherein I’d encourage Daring Fireball readers, whenever they encounter these “Please rate this app” prompts, to go ahead and take the time to do it — but to rate the app with just one star and to leave a review along the lines of, “One star for annoying me with a prompt to review the app.”

Of course, by alluding to such a campaign in the plain view of hundreds of thousands of readers, Gruber may in fact have launched it. I witnessed many hoots of agreement among folks on Twitter, but also this more considerate reaction from Cabel Sasser of Panic:

That said, ‘give apps that do this 1 star’ suggestion bummed me out — stoops to the level of ‘1 star until you add X feature!’

Damn you, Cabel, and your empathetic rationality. There’s something to his call for civility and for taking the high road. On the other hand, damn it, too many developers have chosen the low road and users are entitled to react accordingly!

Probably the most uncomfortable aspect for me of this debate is that the temptation to … encourage users to write reviews and to rate software is completely rational. It makes perfect sense for us as developers to do everything we can to maximize the positive marketing of our apps.

But every choice in business comes with consequences, positive and negative. You implement a new feature that wows half your audience and increases sales among them by 10%, only to discover you’ve pissed off the other half and cut sales by 50% in their camp. It’s not fair or necessarily even rational. It’s just the mechanics of choices, reactions, and consequences.

Many developers cling tightly to the belief that because positive reviews can lead to increased sales, it’s unambiguously right to encourage more of them. And if producing a small number of reviews is a good thing, then producing a huge number of reviews must be a great thing. Mo’ reviews, mo’ money. What’s the problem?

The problem is that except to the least soulful among us, maximizing sales is not the only goal of writing software or developing a business. We need sales to keep ourselves and our families comfortable, but we need other things too. To many of us, these priorities are at least, if not more important than the specific need to make a living somehow:

  • The satisfaction that our customers are being treated well.
  • The ongoing support of customers for months and years to come.
  • The sense of pride in owning and stewarding a well-crafted product.

It’s smart to take it as given that something should be done to encourage users to leave positive ratings and reviews. That’s good business sense. But also take it as given that the farther you tread in the direction of badgering and disrespecting users, the more you chip away at the meaningful non-monetary benefits listed above.

If somebody like John Gruber incites your customers to rebel against the choices you’ve made in designing and marketing your product, take a step back before condemning him as the problem. Whether they knew it or not, your customers were already pissed at you before reading Gruber’s opinions. He’s only providing them with a context for expressing that rage. Take it as a wake up call and as an opportunity to re-evaluate your behavior before too many additional customers are moved to act.

Heavy-handed efforts to drum up reviews that produce a cash influx today might lead to unwanted consequences down the road. You might end up unsatisfied and ashamed that your otherwise brilliant app stoops to nagging and infuriating its users on a regular basis. And to top it all off, somebody like Gruber might light the match that sets them off revolting against you. It won’t be his fault, because the choices were yours all along. The consequences? Those are yours as well.

Instant Gratification

Technology consistently upgrades our standard of living, often in ways that we inevitably take for granted shortly after.

One of the best upgrades of the past few decades for so-called individual contributors like myself has been the extent to which we can now publish our work, receive feedback, and move forward in the process of perfecting our art. All within a few days or weeks rather than months or years.

In the old days, people like us worked in solitude or with the feedback of only a few confidants. A wider audience would evaluate the work only at major milestones: when a story was published, when an illustration was printed, or when a piece of software had passed through so many internal hoops and jumps that a publishing company agreed to release it to the open market.

These days, people who are confident they can do good work face one primary obstacle: the challenge of doing that good work. When the job is done, or even half-done, a dozen, hundreds, or thousands of eager constituents stand ready to judge it.

That’s terribly frightening and terribly enlivening. No more waiting for permission to share your thoughts, arts, or inventions with the world. And no more excuses for holding back. Got something to give? Put it out there and see what sticks.

Of course this freedom of expression comes at a cost: anybody can publish anything at any time. Most of it will be terrible, and much of it will be of lower quality than the highly-edited content of yesteryear. On the one hand, it encourages flippant blog posts like this, where perhaps the content should have gone through more than a ten-minute review process. On the other hand? Nobody with something profound to share should ever be silenced again.

The Integrity Prize

Alicia Liu paints a compelling picture of Salesforce as scoundrels, or at least oblivious, in their recent hackathon. They promised a $1M USD prize to whichever team of developers could present the “best” product submitted in compliance with the contest’s rules. The questions being raised have to do primarily with whether or not the rules were upheld.

Liu participated in the hackathon, and shares her first hand experiences of problems she observed. I learned about this story from Marco Arment, who points out that Salesforce will likely suffer a developer backlash from the airing of all this dirty laundry. It would be unfair to condemn a company based on the testimony of one participant, but her account reads authentic to me, and seems to be supported by comments on Hacker News. (I know, not the world’s most reliable source).

The most galling points to me from Liu’s report are:

  1. The winners of the contest seemed to be in violation of both the spirit and the letter of the rules.
  2. Multiple participants’ submissions seem to not even have been evaluated.

I believe that in general bending the rules is a valuable exercise. But when it comes to judged competition of any kind, whether it be on the sporting field, at the local trivia quiz, or in a $1M cash prize hackathon, a contest is only as good as its compliance with the rules. Any participant in the Salesforce event whose diligent, rule-abiding effort was either ignored completely or dismissed as inferior to the work of a rules-shirking participant, is right to be indignant about the outcome of the event. The rules of this contest, both the grandiose prize, and the significant surrender of IP rights required by the rules, make the apparent jerking around of participants that much more distasteful.

As much as it irks me to learn of companies exploiting programmers, it bothers me on a more personal level that so many developers are eager to surrender both their time and their integrity to participate in such events. Whether it’s out of hope for a $1M jackpot or, perhaps more troublingly, based in the desperate pursuit of any external validation of their work, these are not ideal outlets for the most talented developers in any field.

Few of us are immune to the lure of prizes and recognition. Every spring, most of my friends and I start gossiping about, maybe dreaming about, the potential winners of the Apple Design Awards. These are conveyed every year at Apple’s Worldwide Developer Conference. While Apple seems to stick to the letter of its rules pretty well, the rules themselves sometimes seem capricious, and are not announced until a few months before the “contest.” Nonetheless, myself and others have been caught up some years toiling away on products or features that we wouldn’t otherwise be focused on, all in the vain hope of winning the coveted prize. At least in this scenario with Apple, we may be sacrificing a small amount of integrity, but aren’t outright donating our IP to the company.

I’m reminded by hackathons like Salesforce’s, by Apple’s Design Awards, and even by awards I’ve been humbled to receive such as the Macworld Editor’s Choice Award, that as great as it feels to win a contest, prizes like these shouldn’t be our primary goal. I’ve joked about it some years, when I inevitably don’t win an Apple Design Award, that at least I’m still winning the Customer Design Award. With that quip I mean to remind myself that winning the favor of these small groups of people with power should never be seen as more valuable than winning the favor of the people who really matter.

Who really matters? Yourself, those who are close to you, and the customers you aim to serve. Start each day determined to win the hearts of those people, and strive to remain indifferent about the judgements of Salesforce, Apple, or any other small group of judges that aims to string you along for their gain. You may not win $1M, but you’ll hold on to the most valuable prize of all: your integrity.

Stagnation Or Stability?

Michael Lopp is moving on from Things, a popular to-do management app.

That’s an understatement. The title of the post is “R.I.P. Things,” and he wastes no time explaining that he is “throwing away” the app. This sounds juicy. What could have him so riled up?

How can I trust that I’m using the state of the art in productivity systems when I’m using an application that took over two years to land sync I could easily use? What other innovations are they struggling to land in the application? Why hasn’t the artwork changed in forever? What is that smell? That smell is stagnation.

The nut of Lopp’s rationale for tossing Things to the curb is the relatively slow pace of its development over the years. Delays in delivering long-desired features, namely sync, made him conclude that the software will not evolve in ways that suit his needs moving forward. He’s not giving up on Things because of specific shortcomings, but because of anticipated shortcomings and a loss of confidence in the developers of the app.

This line of reasoning gets my hackles up in part because I’m a cautious, deliberate developer. I tend to add features, rework user interfaces, and adopt new platforms at a pace that frustrates even my most loyal customers. I’m slow, but I’m good! When Lopp attacks Cultured Code, the makers of Things, and questions their core competence, I feel that I am being attacked as well.

But what really frustrates me in this case is the software has served him perfectly, and he thanks it with a slap to the face. It’s one thing to denigrate a product for failing to meet your expectations, or for exhibiting a clear lack of craftsmanship, but Lopp admits that those problems do not apply:

Part of me has been fine with this lack of change because I don’t need my productivity system to do much more than capture a task, allow me to easily categorize and prioritize tasks, make it easy to search and filter them, and do all this work frictionlessly. “Things does these things well,” I thought to myself, “I don’t need anything else.”

He applauds the app for allowing him to do his work “frictionlessly.” How does a software developer achieve this level of performance? By first building a quality product and then working deliberately over months and years to address the minor issues that remain. Woodworking makes a reasonable analogy: after a chair has been carved and assembled the job is functionally complete. It’s a chair, you can sit in it. It’s done. But customers will gripe with good cause about its crudeness unless the hard work of detailing, sanding, and lacquering are carried out. Only then will it be considered finely crafted.

As a seasoned software manager, I know Lopp appreciates how hard it is to achieve the stability Things has provided for him. But as a user, he’s as excited as any of us to see new, fresh designs. As an onlooker, it’s easy to associate dramatic change and motion with competence, and quiet refinement with laziness. We must draw on our own experiences attempting to build great things to appreciate how much work takes place in stillness, to have faith that even though things may appear stagnant, a benefit of frictionlessness is resulting. An app at rest may be in that long, arduous phase of becoming finely crafted.

There is a time for dramatic change as well, but it comes with costs. If after years of careful refinement a product is found to be lacking in some important way, bring out the hatchets. Chop it all to bits and rebuild from scratch. The possibilities of positive change in major reworks are exhilarating as a developer, and tantalizing to customers. But every reworked component of a product also resets that process of refinement.

Software should be criticized. Even apps that consistently wow me with their intuitiveness and polish leave me scratching my head about perplexing, nuanced failures. But criticize an app for its failure to do something important, not for an unspecific failure to change in general.

I’ve whined about stagnation, too. I waited years for an update to Keynote and over time, become more and more grumpy about the lack of change. The fact that it’s just about the best application I’ve ever used slowly lost sway in my judgement of the software and, by association, the team of developers who build it.

The next time I’m tempted to think harshly of a developer working at a slower pace than I’d like, I’ll try to step back and appreciate that I care enough about their software to be concerned. And more importantly to appreciate that they care about their software too. So much that they work slowly, deliberately, painstakingly in the pursuit of a frictionless experience for myself and other users.