So I have been working at a startup company for about two months now, and I already learned many great things. I am not talking about new frameworks or programming tricks, but about peer-interaction and productivity. Coming with an academic background to a fully-pragmatic startup is not easy, and I had to learn some lessons the hard way. The best one to date has been the 20 / 80 productivity rule.
The 20 / 80 productivity rule was explained to me by one of my co-workers and is quite simple. In any task, the Effort vs. Result curve looks about the same: you can complete a task up to 80% with only 20% of effort, which means that the remaining 20% of the task will take up 80% of effort. While being an academic or when playing on side projects, it is probably fine to provide 100% of the effort for 100% of the result. However, while being on an agile team in a startup world, you want to reach that optimal 20 / 80 point on the curve, and spend time only on those 20% that give you 80% of the final result. This is really easy to understand, but trust me, it is not always that easy to implement, all the more so when it requires breaking well-established habits. I am not saying that one should be as lazy as possible. Here, “effort” is to be understood as a combination of time and resources.
So what did I learn? I learned that in the real world, perfection is an unnecessary commodity. It doesn’t matter if your algorithm is not super-fast, as long as it’s fast enough. It doesn’t matter if the design of your class is not the best, as long as it is good enough to be maintained and understood by another developer. The trick is to start a task by identifying the different steps necessary to achieve that task, and within those steps the different alternatives and their associated effort vs. result trade-offs. Then, for each step, pick the alternative that gives the 20 / 80 ratio, implement it, and move on.
Here is a graphical representation of this 20 / 80 trade-off that should make it clear:
Hi Emmanuel,
I think I get your point about an 20/80 productivity rule, but sometimes when I’m writing software for a class I feel like I’m in an 80/20 regime. I have to make an 80% effort to get a software project stood up, before I feel like it even begins to have a 20% domain-specific expressiveness. Then the last major results come with a lot less effort, almost for free. So my curve looks like an inverse of yours!
Take care,
Cal in Louisville
Could you please give me a couple of examples of the classes and projects for which you have noticed this pattern? Also, could you very briefly describe what formed the 80% non-domain specific part, and the 20% domain-specific part?
My experience of academia is that it applies the 80/20 rules perfectly: academics typically program so as to have the results they need, that is, publishing a paper, as opposed to have something that works in the real world.
Can your elaborate 80/20 rule more clearly ?; sorry but I don’t understand it give some practical example.
Thank You
I realized only after writing this article that what I was referring to something that is widely known and documented, and more commonly known as the Pareto Principle. You can find more information about it here: https://en.wikipedia.org/wiki/Pareto_principle.