Three Things We Humans Are Terrible At And What It Means For Mobile App Development

Three pitfalls of self-delusion and how humility, flexibility, and knowledge can save your mobile app development project.

1. Multitasking

The term “multitasking” came from my world of computer science. Doing multiple things at once can elusively make us feel as though we are multiplying our productivity, but the actual truth is pretty damning. While you feel more efficient, science says you lose more IQ points when multitasking than when smoking pot or losing a full night’s sleep.  

Whenever I decide to shut out everything and focus on one task, I always find an amazing sense of clarity in my work.

What this means for organizations

The obvious takeaway is that you should minimize what each person is working on. The best option is to make sure people are working on precisely one thing at a time, with a clear path to what they’ll pick up next and total permission to not care about it until it’s officially on their plate. Joel Spolsky argues this point in a wonderful post on how task switches are even difficult for computers and how much they affect humans.

When it comes to your apps, this is why it’s so important to have a complete focus on the job to be done. Don’t force your users to lose brain power by having to manage all the different things your app is capable of. Give them a reason to launch, a clear path to complete their goal, and get out of the way.

2. Abstraction

Abstraction is the process of separating out a general concept or idea from the specific instances of it. In conversation, I can say “office chair” and you have a basic idea of what I mean without explaining casters, hydraulic adjustment, and backrests. The same benefits apply in software, where an object that inherits certain things need not re-implement them.

But we can’t ship an abstraction.

All mobile app projects are about taking us from abstract ideas of what an app should do to the concrete implementation we’re ready to put in the App Store. If you’re thinking $700 Aeron office chair and I roll in a $20 Walmart special, you’re going to be disappointed.

The difficult part is that difference between the two is all in the specifics. We could have spent months diagraming what a chair generally looks like, or spent months documenting features like padded seat, adjustable height, rolling wheels, etc and we’d still be hopelessly disconnected.

What this means for organizations

Get concrete. People will give you far more constructive feedback the more they can react to the actual app itself. An idea that looked great in a wireframe or a comp may just be plain annoying once you hold it in your hand.

In software, we’re able to build things relatively quickly, dismantle and refactor them without causing vast amounts of waste, and iterate into the ideal even if we missed it with our first attempt. The more you take advantage of the quick feedback loop of iterating on real things, the less you waste on misunderstood abstractions.

3. Assessing Risk

If the financial crisis of 2008 should have taught us anything, it’s that we’re terrible at assessing risk. It’s a special form of hubris in mobile – the only thing I know about 6 months from now is that major changes will have occurred.

People often ignore risks even once they’ve happened. For example, a risk is identified – “if we don’t have this API by next week, we can’t move forward.” Later, the risk actually happens – API is delayed. Then the inevitable question: “So we’re still on target, right?” This happens so much our team has a special word for risks that have occurred – we call them a doom.

What this means for organizations

“Blessed are the flexible, for they shall not be broken”

If we can’t assess risk well, how do we manage it? The key is in maintaining healthy margins and an ever present assumption that things will change. This is why I like using an Agile approach to software. Fixing scope, budget, etc means that something must break – quality, features, profit, team sanity – in order to accommodate inevitable changes.

You Might Also Like…

The Line Between “What” and “How”

Introduction A pervasive problem in software development is finding the line between what is a sufficiently detailed description of a product requirement and describing the "implementation details" of that requirement. Put simply; it is a problem of finding the line between what and how. A product requirement should contain everything about the "what" (and leave …

The Line Between “What” and “How” Read More »