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.

Fingerprints As Access Tokens

Everybody seems to have an opinion about the new TouchID fingerprint sensor on Apple’s iPhone 5S. I suppose I do, as well.

Critics object to the idea that a fingerprint sensor, no matter how good, should be used to safeguard critical data. Dustin Kirkland makes the case (via John Moltz) that biometric information is inherently bad as a substitute for a password, because it cannot be “independently chosen, changed, and rotated.”

I take his points seriously, and they seem well reasoned from a security point of view, but they are based upon the premise that passwords are the end-all be-all of security, when in fact common sense proves they are not. The oldest, most trusted, and most widely deployed method of authentication on the planet is in fact “biometric”: the human ability to recognize a familiar face. The fact that my appearance could technically be spoofed does not change the fact that arriving at the home of a childhood friend after 20 years of separation will still earn me an invitation to the dinner table, if not a bed for the night.

So fingerprints make lousy passwords. Who cares? Their use in practice need not replace other authentication schemes, it only needs to augment other schemes in a manner that increases overall security.

Most authentication systems in society are scaled appropriately for the context in which they are deployed. When I travel by airplane, I am asked to show a government ID to get through the security gate, but thereafter, a simple piece of printed paper will get me on a plane. The government takes it for granted that once I’m in the boarding area, the odds of somebody getting hold of my scrap of paper, or my getting hold of theirs, and neither one of us subsequently complaining, are marginally small. Furthermore, if the two of us mutually agree to swap tickets and travel to the other’s destination, we haven’t really caused any significant harm, except perhaps to the egos of the folks in charge at the TSA.

Boarding passes are little scraps of paper that make lousy identification cards. I can’t use them to reserve a hotel, file a police report, or obtain a marriage license. Yet in the right context, I can use one to travel from Boston to Shanghai without a single person batting an eye or thinking twice about verifying my identity.

In this sense the airline boarding pass is like an access token. On the web, an access token is something obtained by stronger authentication that permits continued access with weaker authentication. For example when I allow a Twitter client to connect to my Twitter account, I must first visit Twitter.com and possibly enter my full account credentials. After the access token has been vended however, it serves much like a boarding pass, allowing free access until and unless I or Twitter registers a complaint.

There’s another sort of abstract access token that has been available to users iOS devices since day one: your continuous use of the device. If you have in your possession an iOS device and you abstain from turning it off or letting it sit idle, you retain free access to the various data on the phone. From a security point of view, this token is even worse than a fingerprint: anybody, including the family cat, can sustain it if they are so inclined. Leave a phone on a table for 5 seconds, somebody else picks it up, they have your “activity token,” and they didn’t even need to scan your fingerprint.

I view the fingerprint sensor on the iPhone 5S and other devices as an opportunity for extending this kind of implicit authentication. It’s not a substitute for a password, but rather a convenient token for obtaining streamlined, continued access to protected resources. It’s the boarding pass that prevents you needing to take out your ID, and go through a body scanner or pat-down again, just to get on the damned plane.

We can argue about whether Apple has chosen the right boundaries for where a fingerprint should be traded for full authentication, but as a technology it stands to fill that gap between the frighteningly insecure “unlocked while active,” and frustratingly unusable “full authentication required when inactive.”

In short, I would like to see fingerprint authentication deployed in a way that pays respect both to the relative convenience and the relative insecurity of a fingerprint. If I can for example configure my phone to require a fingerprint unlock after 1 minute of inactivity, but to require a passcode unlock after 30 minutes of inactivity, my concerns about fingerprint security would be effectively put to rest. Could a malicious person steal a high quality impression of my thumb print, construct a prosthetic, fleshy representation of it, and use it to unlock my phone? Perhaps. But if they can’t do it within half an hour of stealing my phone, they better get to work on cracking the passcode.

A Mockery Of Whom?

Are Marissa Mayer and Yahoo!’s design team playing the fools, or playing us for fools? I honestly am not sure anymore.

When the company announced more than a month ago that they would debut a new logo, I was surprised to learn that before sharing it with us, they would subject themselves and us to 30 days of lackluster logos. It felt to me like a lapse in judgement to:

  1. Put off for even a day the fresh new logo that was prepared to move the company forward.
  2. Accept for even a day, let alone 30, the use of any logo that had not made the cut.

But I sort of laughed it off, snidely and then crudely shared my thoughts on the matter, and waited out the 30 days.

Last night Yahoo! finally revealed the new logo, and the mildest reaction I can possibly muster is that it does not appear to be a professional design:

Yahoo's new logo, September 2013.

Because I myself am not a professional designer, I am tentative about making specific judgements, but my relatively untrained eye reacts to several problems with logo. The beveled characters make the logo appear dated and distractingly three dimensional. The scalloped edges lead the eye away from forming any unified shape. The lightness of the strokes, particularly in the bar of the A and H makes the whole thing feel fragile and not suited to scaling very large or very small.

A snarky summary of my criticisms would be to say that it looks like something somebody threw together in a weekend. Upon seeing the new logo I tweeted that I hoped it “was designed by committee, because I don’t want to imagine an individual taking the brunt of reactions.”

Marissa Mayer herself chimed in on the new logo, so now we know that both are true: it was designed by committee, and it was thrown together in a weekend:

So, one weekend this summer, I rolled up my sleeves and dove into the trenches with our logo design team: Bob Stohrer, Marc DeBartolomeis, Russ Khaydarov, and our intern Max Ma. We spent the majority of Saturday and Sunday designing the logo from start to finish, and we had a ton of fun weighing every minute detail.

Expletives are begging to let loose in my typing. You have to be kidding me.

This is not how any company, big or small, cherished or unknown should design a company identity. The more I read about Yahoo!’s process for this redesign, the less respect and confidence I have in them. As a minor Yahoo! shareholder and a long-time, sometimes grudging fan of the company, I am not sure where to go with these feelings.

It’s that point of gullible disbelief where one starts to look around for hidden cameras. Are we being punked? Is Marissa Mayer merely making a mockery of Yahoo! and its identity, or if she is snickering churlishly as she pulls off an elaborate prank, hi-fiving her co-conspirators as they witnesses the world react jaw-gapingly to their purported pride in these actions?

The Imperfect Craft

For much of my career I viewed software development as a craft: a constructive endeavor with fixed standards of excellence. I thought that over a lifetime, I could assiduously refine my skills, inching toward some level of subjective mastery until eventually myself and others would agree that I had become “a real expert.”

Unfortunately it doesn’t work that way with software. The technological context in which software is developed and used changes constantly and dramatically. So most of the stringent guidelines we impose upon ourselves in the name of craftsmanship are at risk of being obsoleted by some new advance in hardware, in programming languages, or in the baseline services of the operating systems we develop for.

Ask yourself, or a software developer of a certain age: what were the guidelines for crafting excellent software 5 years ago? 10 years ago? 20 years ago? The farther back one goes, the less relevant the answers will be to our modern craft. Memory management? Not a significant issue for most programmers today. Multitasking? Obliterated by modern operating systems with efficient context switches. Concurrent programming? Constantly reinvented in the wake of multi-core CPUs, GPUs, and higher-level programming language features.

I have spent a lot of my professional life honing “the skills of programming.” That is, the set of skills that seemed important at the start of my career. But I’ve seen what happens to people who cling to outdated standards of craftsmanship: they become self-righteous, bitter, and delusional. Guided only by the hallowed rules of yesteryear’s geniuses, they and their work become marginalized. Without a foothold in the modern technological context, programmers who should be great are rendered effectively incapable of developing their craft.

I’m sure this problem is not limited to software development, but given the world’s obsession with computers and related technology, the software landscape is changing much faster than many of us can easily keep up with. The world demands that this craft change. The technology for sculpting, firing, and glazing a ceramic bowl has also changed over the years, but not at the same mind-boggling rate as prototyping, programming, and testing a software application has.

What if you happen to enjoy old-school programming? There’s nothing inherently wrong with crafting “retro software.” In fact, I’m sure that dabbling in outdated techniques will serve to round out a modern programmer’s abilities. But while a classics scholar may be intrigued or even obsessed with ancient Greek or Latin, she knows that in order to remain relevant she must publish her papers in modern English. And if Esperanto were to become the lingua franca for her craft, that is the language she would have to use.

In software, the lingua franca is changing all the time, whether by adoption of new programming languages, through nuanced idiomatic changes in the ways that we use languages, or because of evolving operating-system level facilities. We don’t have the luxury of assuming that the tools and techniques of our parents, or even our younger selves, are sufficient to move the profession forward.

As a modern software developer, I derive as much joy from remaining relevant as I do from the thrill of identifying and solving the particular problems in my work. To remain relevant, I have to reject my previous assumption that I would spend a lifetime refining my craft. Instead, I will spend a lifetime adapting the techniques of yesterday’s craft to the sometimes radically different challenges of today. I may never become “a real expert,” as I hoped I might be. But by diligently throwing out the old rules and embracing the new ones, I hope to come close.

Assembled In USA

Apple has reportedly begun promoting the new Mac Pro, of all products, in US movie theaters. John Gruber linked to the story, commenting on the apparent disparity between mass movie-going audiences and a pro-market computer:

Impressive marketing move for a product that is by all means truly “pro”.

One objective of the teaser is to remind everyday American movie-goers that Apple continues to innovate in computer hardware. The teaser emphasizes Apple’s ability to design beautiful hardware and to push the envelope of how a computer looks and feels. It serves to remind the public that Apple is both capable and cool.

But I expect the other goal with this spot is to appeal to American pride. Why promote an expensive, niche-market computer like the Mac Pro to everyday Joes and Janes across the country? Because on top of being an innovative, beautiful, envelope-pushing piece of hardware, it will be made right here in the USA.

I haven’t seen a verbatim copy of the trailer as shown in theaters. Apparently it ends with a headline indicating the Mac Pro will be available “Fall 2013.” I will be surprised if it doesn’t also subtly allude to its American manufacture. A small percentage of folks who see the ad will leave the theater committed to purchasing a Mac Pro this Fall. A far greater percentage will leave the theater convinced that the Chinese-manufactured iPhone or iPad they’re considering for Christmas is part of a great American tradition. And they’ll be right.

Update: Reports from folks on Twitter indicate that the movie-trailer features no such mention of the Mac Pro’s US assembly. That strikes me as a shame and a missed opportunity particularly considered the hyper-focused US market for the ads. Another compelling theory from Drew Pickard suggests that running ads for the Mac Pro in movie theaters is a good way to make sure every movie-making professional is aware of the computer, and will consider purchasing them for their production teams.

Mercurial Plugin For Xcode

Raphael Sebbe (@rsebbe) put together a nifty plugin for Xcode (version 4 or 5!) that coerces Xcode into substantially supporting Mercurial, in addition to its native support for Git and Subversion.

The plugin builds upon an existing script that essentially acts as a Git-facade around Mercurial. Swapping the script in for Git is sufficient to cause Xcode to think it’s dealing with Git, when in fact it’s dealing with Mercurial. Pretty clever. The plugin takes this a step further by appyling some runtime patches on Xcode to improve the handling of Mercurial repositories.

Although Raphael calls it a plugin, and it does extend Xcode, it’s important to recognize that Xcode doesn’t provide an official plugin mechanism. Not even for revision control solutions. This makes the achievement even more admirable, but should also inspire you to proceed with caution if you choose to try the plugin out.

As explained in the project documentation, the plugin is still experimental and doesn’t support all of Xcode’s Git-based features. Still, it’s a nice start, and I appreciate the spirit of rallying Mercurial fans to fill the void that Apple has left in choosing not to officially support Mercurial.