#iOSDevUK: Hamish Allan – The Pareto Principle

80/20 modular framing
Credit: Flickr / Alexander Pfeiffenberger

App store offered a way for people who were interested in writing software to make money from writing software.

Have recently found need to do more advertising. Even more recently, take on more and more contract work.

Identify as devs, but need to learn more sides of running a business. Pareto principle is thing that can help here.

What is it?

  • 80:20 rule of thumb.
  • Doesn’t have to be 80 and 20.
  • Doesn’t even have to add up to 100.
  • 80% of effects come from 20% of causes.
  • Cause and effect are not necessarily linearly related

Vilfredo Pareto

  • 80% of the land is owned by 20% of the people.
  • Economics based on observation, transformed into scientific discipline.
  • Adam Smith was more of a philosopher.
  • 80% of peas come from 20% of pods.
  • In 1980 countries with richest 20% of world population had 82.7% of GDP.
  • Up from 70.2% in 1960.

If you have an 80:20 rule, alpha param has a value of about 1.16.

Project Management

  • 80% of value is achieved with the first 20% of effort.
  • The last 20% of an app takes 80% of the time to write.
    • If writing a mail app, got table view done, might think 40% done, but only 1/600 of the way there.

Your own apps

  • Five 80% coplete apps versus one 100% complete.
  • Ask, should I be writing more apps?
    • Do you write one app and make it the best you can, or diversify.

Contract Work

  • If possible, avoid estimating for completed projects.
  • Easier to estimate 80% of what they want.
  • Bid for a phase 1. 80% of what they want, in 20% of time.

In Engineering

  • 80% of bugs in 20% of code.
  • A large number of bugs come from a small number of classes of bugs.
    • E.g. memory management. Arc destroyed a large class of bugs that took up so much time.
    • Multithreaded programming. Dispatch queues address this.
    • Asynchronous programming.
    • Type safety (swift).
  • 80% of processing time is spent in 20% of code.


  • 80% of your app’s usage is 20% of it’s features.
  • Optimize for the common case.
  • Especially at resume time.
  • Be opinionated
  • Especially if you change rather than just adding.
  • They will ask you to add a switch in settings. Try not to do that.
  • Paradox of choice – if you present a lot of choices, it stresses them. Makes the app less usable for them.
    • Developers might be OK with it but a lot of people find it stressful to be presented with so many choices.


  • 80% of your support is for 20% of your customers.
  • Check if they haven’t paid and ask for support.
  • Like getting blood from a stone. Try and engage in a conversation just don’t.
  • Answer terse emails briefly.


  • Not quite as applicable on the app store because leads don’t work the same way.
    • 80% of sales come from 20% of your products.
  • 80% of your clients come from 20% of your leads.
  • Don’t do too much work for free.


  • 80% of work is copleted by 20% of individuals.
  • 80% of work is completed in 20% of an individual’s work hours.
    • Hard to optimise for that, downtime is important for perspective.
  • Best teams have people who can code quickly, and people who are always trying to put the breaks on and take a wider perspective.
    • Need both of those types of people and everyone else in between. Or individuals taking both of those approaches.

Bunch of places where you can apply. Helpful for people who want to make a business coding.

You must measure. It’s a discipline. You can make assumptions about where the low hanging fruit are, but until you measure you don’t know.

One reply on “#iOSDevUK: Hamish Allan – The Pareto Principle”

Comments are closed.