I Believe in Karma

I believe in Karma. Not exactly the mystical Hindu concept, but the idea that you generally get what you deserve. I believe in it because it makes total sense.

Think about it this way: we’re all part of this system we call “society.” What we do contributes into this system, and what we experience draws from it.

It only makes sense, then, that the more good we do, the more good experiences we inject into the system. The probability that we will eventually experience good from the system then increases accordingly. The same process also works for evil.

Good tends to beget good, because it tends to cause the recipients of the good deed to probably improve their mood, which causes them to do more good things than they would otherwise, and so on. But that’s not all. Thanks to Herd Bahavior, we tend to copy what we see others do. The more good you do, the better the chance that someone else observes you doing good, and the more likely they are to do good because of you. What you experience from society, then, is nothing more than an aggregate of the decisions made by its individual participants, including yourself. The concept of Karma is just an observation of this phenomenon.

These sayings are equivalent:

• Do unto others as you would have them do unto you
• You will reap what you sow
• What goes around, comes around
• Pay it forward

The whole idea of Karma is profoundly empowering. You, it turns out, are responsible for your own well-being. You are not a victim of your circumstance, because you are an active participant (by deciding what you will do) in creating that circumstance. And you have the power to improve your experience through the choices you make.

So the next time you have a choice between doing good or evil, please choose to do good. After all, the one who will benefit the most may just be yourself.

“The No Asshole Rule”

I read Robert Sutton’s book, “The No Asshole Rule” in one day. It turned out to be a surprisingly entertaining read, and best of all, it’s full of insight. This book ought to be required reading for everyone entering the workforce.

What Sutton calls an asshole is a beast known by many names, such as jerk, bully, asshat, etc. But no moniker is so universal, so visceral, so essential as “asshole.” Great choice!

Sutton’s book confirms what I suspected about the role assholes play in the workplace. In fact, many of the observations Sutton makes harmonize quite nicely with my Top Ten Rules of Software Team Success, especially rule 0 (hire for fit, not just for skills). One bad apple (a.k.a. asshole) can and does ruin it for the rest of us.

In one chapter Sutton computes the Total Cost of Assholes (TCA) for a company dealing with a jerkish, but very successful employee. Aside from being great fun to do, computing a TCA shines a light on the very real cost of having assholes in the workplace. In his example, the superstar salesman who was also a “certified asshole” had demonstrably cost a company $160,000 in asshole management time the previous year, not counting the indirect costs due to the lowering of team morale because of his boorish behavior. With this cost added to the balance, it turned out that he wasn’t so good for his company after all.

As sure as there is an exception to every rule, there are exceptions to the No Asshole Rule. One chapter is dedicated to “The Virtues of Assholes,” that is, situations in which being an asshole actually helps instead of hinders. In my opinion, it appears that it pays to be an asshole when you have to play the role of the Benevolent Dictator. This role should only be played strategically, and very, very rarely. And you had better be damn sure you have a vastly superior idea that nobody else understands, and that they should just shut up and do as you say; that is, the end result had better show that you were absolutely right all along. Otherwise, all you get is to be a bigger asshole than you already were.

Until we rid all workplaces of all assholes (it’ll be a while), many of us need to deal with them everyday, or at least survive them while we send out résumés to look for places less infested. Sutton provides a whole chapter of coping strategies, including avoidance and emotional detachment. But managers take note: although these strategies are effective, they will cost your organization untold wasted time. It’s far better to observe the No Asshole Rule and fire known assholes rather than let them waste your dollars.

I highly recommend this book. It’s light reading that’s packed with wisdom. The more organizations adopt the No Asshole Rule, the better this world will be.

Hello Apple, Goodbye Apple Topics

It’s official, folks. I’ve been hired by Apple Inc to work on iPhone software. I start work in February.

While this is undoubtedly a terrific career opportunity for me, and (I hope) a mutually beneficial arrangement with Apple, I’m sad to say that I will no longer blog about Apple’s products, its direction or its philosophy. It’s not just because of their tendency towards secrecy (that’s a factor, too). But it’s that my words, however unlikely, may be construed as inside information. 

So to avoid misunderstanding about which words are my honest opinions and which are derived from my knowledge from the “inside,” I’ve decided to stop talking about Apple altogether.

I’m very excited to join their team. I think the iPhone is a bona fide breakthrough in handheld computing, and it represents the Apple ][ of this generation. I’m deeply honored to join their team.

And that’s my honest opinion.

See you in Cupertino!

The Top Ten Rules of Software Team Success

I’ve been doing software engineering for ten years now (the past three years as lead), so I think it’s appropriate for me to look back and reflect on what have worked and what have not in the world of team dynamics. To keep it short, I’ve decided to write a top-ten list of rules. Follow these rules, and your team will likely succeed in producing a successful, elegant, and satisfying product. Break them, and success is that much farther away from your grasp: at best, you will make a boring product; at worst, you will fail spectacularly.

Although I have come to these rules by my own experience and conviction, I owe a great intellectual debt to Jim and Michele McCarthy, and their research culminating in The Core system. Run, don’t walk, to the bookstore and buy their books.

Here we go.

9. Know What You’re Making, and For Whom

Corollary: Beware of Software Requirements Documents.

Writing and sending around a detailed Software Requirements Document (SRD) for approval is more or less a colossal waste of time, because it is obsolete upon arrival, and a poor substitute for a shared product vision. In truth, writing an SRD is usually a way to avoid having to rally the team to actually understand the problem. Having an SRD allows you to pretend your team understands the problem because you can point at a stack of printouts as “proof” of understanding.

The only way to make a quality product is to make sure your team knows what you’re making, and who your user is. Work this out relentlessly with your Marketing and QA departments. Do nothing, write no code, plan no schedules, until everyone “gets it.”

An unexplainable, divine magic occurs when everyone gets it. When your sole focus (and the only criterion that matters) is the complete satisfaction of the end user with your solution, all other questions are easily answered. Feature lists are easily compiled. To-do lists (which is what an SRD basically is) are automatically maintained and checked off, and no document is written unless needed (hint: most documents aren’t needed).

8. Beware of Meetings

Meetings are the heartbeat of dying projects. Notice that the more your project is in trouble, the more meetings you have to attend? Here’s a public secret: most meetings are a waste of time. They are a drain on your resources (figure out how much salary you’re handing out to a bunch of people sitting around in a warm room nodding off), and an assault on morale.

There are only three valid reasons to hold a meeting, and they are:

1. Dissemination of knowledge, i.e. live training or announcements of great importance
2. Decision-making (see below)
3. Polling for status for the team’s own benefit (and not just the meeting organizer’s)

I hesitate to include the third one because unless people share status and status only, the meeting can easily lead to the violation of the next rule…

7. Beware of Discussion

Discussion is what makes meetings so deplorable. Discussion involves various pairs of people putting on oratory performances before an audience, while others try to get their opinions in edgewise. This usually happens under the guise of “problem-solving.” Because blathering debates and fragmented opinions is what you get with discussions, decisions made (if any) tend to be half-hearted, hasty, and poorly made. Contrary to popular belief, less wisdom is aggregated during discussion than during individual reflection and private conversation.

6. Insist on Unanimous Decisions

The alternative to discussion is a relentless drive towards decision-making. To that end, the Decider and Resolution protocols of the Core are invaluable.

One sign of a thriving team is the regular formation of unanimous decisions. Unless a unanimous decision is reached, the team will be fragmented and unaccountable for their actions. Unless everyone is “in,” one member of the team can later blame another for doing what he thought was a bad idea in the first place. “I told you so” is a poor substitute for quality.

5. Your Rank Doesn’t Make a Better Product

In a successful team, organizational rank means nothing. Voluntary respect is the only coin in the realm that carries any value.

When a team lead, manager, or some bigwig simply insists that his idea is better than the team’s collective wisdom without further justification, then the end is very near. Anyone who does not submit his idea to the examination, improvement, and possible rejection by the team is not a part of the team, and should be removed from the team. I have seen brilliant teams reduced to incompetence by a know-it-all superior who “takes charge” by shoving his ideas down the developers’ throats. 

When the focus of your team becomes “how to avoid getting hassled by the boss” instead of “how to make the best product for the user,” all hope of delivering a quality product is basically lost. Resist, revolt, and send out your resumé, because your energy and passion is too valuable to waste in a team like that.

4. Small Teams are Beautiful

I find that the optimal size for a team is somewhere between three and seven people. This number of people appears to be most efficient in making and implementing rapid, unanimous decisions. They also appear to make really good architectural choices for some wonderful reason.

If a problem cannot be directly addressed by a group of three to seven smart people, then the problem is probably ill-defined or poorly scoped. Work on defining the right problem first, then solve it with a small team.

Sometimes, your group will be far larger than this when some grand decision needs to be made that will affect everyone in your team. In this scenario, instead of directly engaging everyone in the team, or worse, voting for an architectural choice, allow the team to self-select a small group of trusted proxies, who will then decide the general philosophy for the remainder of the team.

This phenomenon usually occurs naturally. The initial kernel team for the project tend to become proxies for their respective areas of specialty in the system. As more people are added, this process recurses to deal with finer and finer details of the design.

Your team must be functional enough that you never need a large number of people to agree on any issue before the team can proceed. To allow this, you must encourage team members to fluidly associate with one small subteam after another as the project evolves.

3. Use Sprints to Focus Energy

I have a whiteboard that I use to direct the team’s energy to the next milestone or goal. On it I write a short description of the next, immediate goal, and under it I write the number of workdays remaining before it’s due, in large type. Each morning, I decrement the number. When the number hits zero, the deadline is here. When we’re late, I write negative numbers.

Key to this technique is to have the team (and all interested parties) unanimously agree up front that the next milestone is exactly what is desired, and that the number of days allocated is appropriate to the task ahead.

Keeping such a visible reminder of the next milestone is highly motivational. It provides a visible challenge to the team, and focuses their attention to perform only those tasks that contribute to meeting the goal. And it gives non-software stakeholders (Project Management, Marketing, and others) a visual reassurance that the team is making steady progress (and it keeps them out of your cubicle).

Meeting a goal even two days early is always cause for a little celebration and high-fiving in the team. This will keep your team energized and focused as they challenge themselves even more for the next milestone. Nothing builds your team’s confidence like small, regular victories.

2. Use Modern Version Control Techniques

There is no more excuse for a software developer to not understand how branch-and-merge version control works.

The use of modern techniques allows individual developers to create features at their own pace, while at the same time maintaining a known-good trunk (see below). Insist on a competent, lightweight, optimistic (no lock required) version management tool (Subversion is great), and always branch before doing any work.

The exception to this rule is if you are working on a small, isolated component, that will later be integrated to a larger product. But even then, as the team grows, make sure that your version control strategy is ready to switch to the branch-and-merge philosophy at the drop of a hat.

1. Always Have Working Software

Whatever version control tool you use, you must maintain a trunk that shows solid operation of whatever features you have implemented so far. The trunk must be buildable, and the trunk must run.

This is the secret to delivering software on time: it’s the idea that you can release your software at any time. Only then can Project Management or Marketing become empowered to decide how many features is enough for a successful product launch. Remember, accurately scheduling software delivery is an impossible task (otherwise we won’t have the dismal rate of on-time software delivery that we see in the industry), but having the option to release what you have when the time is right is a huge business advantage.

0. Hire for Fit, not Just for Skills

A department manager once asked me, “What is the greatest source of variance in a software team’s performance?” At that moment, he was looking for some productivity metric that he could use to give him advance warning of trouble. To his surprise (and apparent disappointment), my answer was “people.”

The effect that individuals have on a team’s productivity is staggering, and it swamps out all other metrics. It is important that individuals in the team work well together, laugh together, and dream together. While individual performance differences are huge (I have a rule I call the “25-to-1 rule:” one developer can solve a problem 25 times faster than another), the productivity advantage of the most brilliant genius in the team can be quickly and very effectively neutered by the one bad apple.

While skills can be learned, a poor fit will guarantee your team’s mediocrity. Hire only the best, and the best for the team.

The corollary to this rule is that you must fire people that act like jerks, no matter how skilled they are.

The New Rationalists

Goodbye, 2008, and good riddance.

Goodbye to the wretched Bush-Cheney administration and the multitude of disasters they wrought upon the world for eight interminable years. Goodbye to the emperor. Hello to a new year, a new president, and a changing of the guards.

Goodbye to the Baby Boomers: you were the Greediest Generation. You left your children with a merciless yoke of debt, an infrastructure neglected and worn, and an economy drunk with pleasure, but crippled by the murder of the very industry that forms its foundation. You have entered retirement at last, so enjoy your last sip of the fruits of your offsprings’ labor as you make way for the new.

Goodbye to America the inexhaustible. She explored the limits of her economy, her military, and her capitalism—and found them. Hello to the good friend of the world, a partner to the strong and weak alike, the new America, humble and kind. We may yet realize we’re not that different after all, we citizens of the earth.

Goodbye to worthless party politics. Goodbye to the sluggard, who votes for his father’s party to the detriment of his sons. Hello to skepticism and doubt. Hello to choosing whatever works and whoever will, regardless of their banner.

Goodbye to fantasy. Goodbye to those once-famous wizards of Wall Street, clever crooks in fancy robes. Hello to reality. Hello to hard work—no, smart work—that good old engine of our economy.

Goodbye, 2008; you won’t be missed. You and your heady magic, your impossible promises, and your seductive lies; you and your disastrous fall. May you lie dead and buried, but not entirely forgotten.

Hello to the skeptics, the doubting, the enquirers driven by persistent hope. Hello to the extended hand, ready to fix the damage with greener growth, new friendships, new ways of thinking. Hello to the ones with open eyes, who realize that all-abundant resources are all around us, if we would just get up and walk a little.

Let’s raise our glasses to the new year, to the people who grasp it by the horns.

Here’s to whatever works.

Here’s to the New Rationalists.

The Netbook Niche

The rising popularity of netbooks is indisputable. But who uses them, really? From a short, completely unscientific survey I conducted (and a lot of guesswork), I’ve come to the conclusion that people buy notebooks primarily as second computers, something to carry with them when they don’t need all the power of a laptop.

Most users want to use netbooks for:

• Internet access, mainly web access and email
• Listening to music and watching videos
• Reading e-books
• Chatting on instant messaging clients (sometimes with video)
• Accessing web-based applications such as Google Apps
• Playing games (usually web-based and not very graphics intensive)

Some hard-core users run local heavy-duty applications on these diminutive machines, but few actually enjoy the experience.

The typical span of time people spend on each session appears to be somewhere between five minutes and half an hour.

Given this usage profile, it’s clear why people don’t use their smartphones instead. Here are the reasons I came up with:

• Smartphone screens are too small for comfortable web viewing. Netbook users want to lean back and browse the web, but smartphones tend to make them hunch over to peer at tiny screens.
• Smartphones are too slow. Due to power constraints, their CPUs are simply not powerful enough to render web content quickly. Netbooks can burn more power just because they have bigger batteries.
• Smartphones have tiny keyboards, or none at all. Although netbook keyboards won’t be my primary data entry tool, they are a lot easier to use than smartphone keyboards.
• Smartphones don’t have a mouse pointer. Since Web 2.0 content is normally designed for a desktop environment, the lack of a mouse pointer makes using web apps very awkward. Try using Google Apps on the iPhone if you don’t believe me.

On the other hand, a netbook is not a PC either. Here are the usage differences I can name:

• Netbooks are used for shorter sessions. A typical user may turn a netbook on, check his email, and shut it down again.
• Netbook users tend to use one application at a time. Due to the small screens, it is inconvenient to interact with more than one app at a time.  Apps tend to be maximized to take up the whole screen. Also, due to the limited resources, running multiple apps smoothly can prove challenging. 
• Netbooks have to be more rugged than laptops. Netbooks must withstand harsh treatments such as being put in a backpack with no protection, and bumped and jostled during transit.
• Netbooks have to be much lighter than laptops. Users who would lug 9 lb laptops will complain about a 3 lb netbook. To be truly useful, a netbook will weigh no more than about 1 lb, but anything under 3 lb is probably acceptable.

A proposed niche description

Today’s netbooks mistakenly cram a desktop OS into a small form factor—and people think this is a good thing! A desktop OS is suboptimal for the netbook platform, because it assumes a large desktop, and boundless storage and power. What’s worse, software written for a desktop OS tend to assume those same things.

Instead of merely transferring the desktop metaphor to a mobile device (the same mistake that drove the creation of Windows Mobile), we need to focus on the netbook niche description. I propose the following:

A netbook is a portable and personal network access, communication, and entertainment device for consumers.

Contrast this product statement with a smartphone’s description:

A smartphone is a handheld personal wireless voice communication, lightweight network access, and entertainment device for consumers.

And that of a laptop:

A laptop is a portable general purpose computer for consumers and technical professionals.

Looking at those three descriptions, it’s clear to me that the desktop/laptop paradigm cannot simply be shrunk down to fit in a netbook. We need a new paradigm.

The Netbook Way

Let’s take a look at what characteristics a Netbook needs to have.

Personal

Because of the device’s personal nature, netbook software should assume it will be used by only one user per device, ever. The user’s name and other information should be entered only once, and then be made available for reuse.

Since the netbook is a full-time participant in the global network, each netbook user should be uniquely and globally identifiable so a user can navigate network resources without constantly logging in (with appropriate boundaries for privacy).

Since the netbook contains so much personal information, security is of utmost importance. A sandbox system should be created to prevent apps from gaining unauthorized access, and strong encryption should be used so that stolen netbooks will not easily yield their content.

Networked communication

A netbook should always be connected on the network. This means there must be a variety of ways to connect to the network. The ideal netbook will get to the net through a cellular network, Wi-Fi (and possibly WiMax), Bluetooth modems, or wired Ethernet, and will switch access methods as needed.

Turning off a netbook should put it to sleep, while still allowing an ultra-low-power component to maintain a network connection. The netbook should sound alerts when new emails or instant messages arrive.

Netbook software can assume that it’s always on some kind of network with moderately fast bandwidth. That means that data that can be synchronized to the “cloud” should be synchronized automatically. Software can also assume that intensive data processing can be delegated to server-side applications. This will keep netbook software lightweight.

The opportunities for caching web applications (like Google Gears) abound in netbooks. This may be the first platform where this sort of “cached-web app” paradigm really takes off, and may finally bring web-based applications to the masses.

Entertainment

If there is one thing that current netbooks do reasonably well, it is media playback. There is little to say here except that playing music and videos should be second nature to these devices. It should also be easy to import and synchronize media with a desktop server.

Consumer Focus

The weakness of current netbooks has to do with their general-purpose operating systems. A netbook is not a general purpose computing platform. It is a focused, task-oriented, consumer device. In this respect it is more like a smartphone than a laptop.

Since the typical netbook user is only interested in running one application at a time maximized to full screen, this should be the netbook’s primary paradigm. “Background” apps should be discouraged. If they are allowed at all, such apps should be restricted it to “dæmon” applications such as instant messaging clients (silently listening to incoming messages) and music playback. This paradigm not only fits the user’s behavior better, it also conserves resources as the OS can completely expunge applications that are not being used.

Low Power

Due to its diminutive size, the netbook OS and software must be much more conscientious about power usage than their laptop cousins. This is one aspect of portable computing that netbooks can trump laptops in. A netbook’s size is large enough to enclose batteries much larger than the ones found in smartphones, so with aggressive power reduction it can easily beat a laptop’s battery life many times over. A 10-hour netbook is not out of the question.

Ruggedness

Netbooks should ideally contain zero moving parts and be moisture resistant. Hard disks should be replaced by solid state drives. Keyboards should be constructed with a sealed membrane under the keys. Passive cooling should be preferred. A glass display should be used instead of plastic to prevent scratching. The number of external connectors should be minimized, and those that are included should be covered when not in use (or be inherently moisture resistant).

What We Need

All this adds up to one main conclusion: We need a new OS and a new application paradigm for netbooks. It is not enough to cram desktop Linux or Windows into a small form factor. The new OS will basically present one application at a time, shown full screen. It will be constantly connected and synchronized. It will be personal. It will have strong application sandboxes so applications can be safely installed and removed. And it should come with a full-featured SDK so others can write apps that work in this ecosystem.

Ironically, the netbook that most closely matches this paradigm is the one that never made it out the door: the Palm Foleo.

With the arrival of low-power, high-performance CPUs such as Intel’s Atom, the time has come to revolutionize the netbook market with a paradigm-busting product.

UI Lessons from the BlackBerry Storm

Why bother? That’s the question that ran through my mind when I picked up a BlackBerry Storm demo unit at a Verizon store. The Storm is billed as BlackBerry’s iPhone killer, matching Apple’s product feature for feature: touch screen, app store, and competent web browser. But it promises a UI goodie that the iPhone doesn’t have: haptic feedback. It was this last feature that sent me scurrying to Verizon to find out if someone has finally come up with mechanical touch feedback on a portable device that doesn’t absolutely suck.

The short answer is no. What BlackBerry is trying to pass as haptics in the Storm is not revolutionary; it’s damn near revolting. It is a classic study in feature-itis, executed in a most clumsy and embarrassing way.

You see, what passes as haptic feedback is nothing more than a microswitch under a wobbly, floating LCD/touch sensor assembly (source). That’s it. No software controlled feedback loop. Push down on the screen, and you feel a click. This works even when the device is turned off.

In order to fully exploit this geegaw, BlackBerry decided that this click is required to activate buttons on the screen. Merely touching a button on the screen highlights it for some reason, but does not activate it. How confusing is that? More importantly, what did this behavior afford me that I didn’t already have with a regular touch screen? This extra barrier to data entry gains the user no benefit that I can see.

What’s more, the click conveyed by the microswitch conveys misleading information to the user. With this setup, I get a click no matter if I push down on a virtual button, or merely on a blank part of the screen. If I attempt to click on a button and miss, I get a click anyway, and that leads me to look for visual cues that are not forthcoming. This setup does not afford the feedback that a true haptic system needs to give, that is, informing the user that the software sees what they’re doing. Instead, the false feedback makes the experience disorienting and unnerving to the user. Even the Samsung Instinct’s ho-hum vibrating feedback is better than this.

Lesson 1: It is better not to have a feature, than to have a feature that buys the user nothing; or worse, misleads them.

And then there’s the scrolling. Or should I say, the jerky lag-fest that happens when you slide your finger up and down the screen. If you weren’t sure before that a 3 FPS update rate is inadequate for a touch-scrolling interface, this device will convince you of it. Scrolling is laggy, jerky, and vertigo-inducing, as you immediately lose your hand-eye coordination. If the device cannot update at an acceptable rate, why not adopt a “page-up, page-down” interface instead of touch scrolling?

Lesson 2: Present only interface components that you can support with acceptable performance.

And don't forget text navigation. BlackBerry’s products are renowned for allowing you to zip precisely and quickly from one text field to another (the Pearl’s trackball is probably one of the most intuitive way to navigate the myriad fields that are can be crammed into a tiny screen). Somehow, the Storm has managed to ruin that reputation in one fell swoop.

Email field selection is impossible. You see, the Storm’s UI still crams all the fields into the screen like in other BlackBerry products, but now you have to select those fields with your finger, whose touch area is about twice as large as any single field. As if adding insult to injury, you now have to click down on the screen to select a field (haptics at your service), increasing the chance that your finger will roll to another field during the maneuver. I found it impossible to precisely select a field. On average, I had to click three times to get to the right field (the laggy response didn’t help, either). In this case, I would have preferred an arrow-key pad to help me go to the previous and next fields more easily.

Lesson 3: Match UI elements to the input device.

Keep digging deeper into the device and you’ll discover one head-scratching UI implementation after another that leave you asking, “why the heck did they even bother doing that?” Most of the time, the answer seems to be, “because the iPhone has that feature.” The difference is that the iPhone implements those features well, so the user gains ease of use, while the Storm team seems focused on checking off a list of feature bullets, with little regard to their usefulness.

And that brings us to our final lesson:

Lesson 4: Do, or do not. There is no try.

Implementing a new UI paradigm is not something that can be done halfway. Your choice of UI has profound implications on how your applications must be structured, even how the OS is implemented (especially the graphics processing component). BlackBerry seems to have been caught up in a fear-driven “me too” psychosis driven by the stunning success of the iPhone, and desperately wanted to beat Apple at their own game. Unfortunately, BlackBerry settled on a feature-matching game that led them to slap a thin veneer of UI freshness over the same old back end, ending up with a halfway product, with a mismatched user paradigm.

So my final take on the Storm: why bother? The Bold, Pearl, and Curve are perfectly wonderful devices that are true to their paradigm. Producing a half-cooked device like this is embarrassing. Stick to your core competency, and produce more of those wonderful text-based devices while you develop a real contender.

Update

Well lookie here: the Guardian newspaper appears to feel the same way about the Storm’s UI. “Prod” screen, they call it.