The 80/20 Rule of Software Development
My first company Imonology Inc. is an agile software developer that builds customized systems for clients. Our projects spanned from online games, cloud surveillance, IT systems and lately blockchain.
We made many painful and costly mistakes in our early projects, that were over time and budget. And as a result, we either missed the golden launch time, or didn’t complete the project as intended.
Originally we were a spec-based company, meaning that at the beginning of project, we discussed with clients to agree on a set of spec, and we provided an estimated time and budget. Once both parties agreed the project started.
We also adopted the agile “Scrum” development approach since the very beginning, and took 2-week “sprints” to try to finish the system within the project’s scope and budget.
Unfortunately it never really worked.
The problems that later ensue boiled down to three main issues:
1. Unclear Spec
Most projects start with a vague, directional business goal or concept, and the person who authorizes the project often has a business goal in mind. The business goal is then captured by a set of requirements and spec by a designer.
However, it likely only captures part of the whole picture or overall complexity. Unless similar project has been done before by the designer or team, there’s always elements of uncertainty involved that are quite unpredictable at the start.
2. Communication Gap
Ideas flow from the project originator’s ideas into designer’s documents, then into project manager’s resource allocation of human resource and time, and finally onto the developer’s implementation.
There’s potential misunderstanding at every level, regardless of how well intended the team is. Of course things might be better if both the team and client are experienced. But as humans, we simply aren’t able to fully capture information or instruction 100% along the way.
3. Changing Spec
Specs almost always change, period! This is a reality of software development. To look at it positively, it’s not necessarily a bad thing, perhaps even a desirable one.
Why? Wouldn’t that drive the developer crazy to implement?
It’s a business reality that the world we operate in is always changing, so a goal that’s sensible a month or even a week ago, may not be as sensible now. Also, new realities always surface along the way.
For example, a difficulty tech issue may not have been foreseen, or a potential design flaw isn’t discovered until the system is used by actual personnel in real workflow.
Changing requirements (and spec) thus is a reality, the question is: can the developer / development approach be flexible enough to accommodate new realities as they surface?
Traditionally this often becomes a tug-war between the client and the developer, where the client may wish to reflect the new reality, while the developer would try to protect the original spec, or ask the client to pay more.
We have since embraced the concept of “Extreme Agile”, meaning that we try to make the whole agile cycle of design-develope-test-feedback, to happen as quickly as possible.
In fact, we try to provide clients deliverables that can be used to provide feedback on a daily basis. Our development project works now like this:
1. the client first describes all requirements and we turn it into a rough spec list with priority.
2. each work day, we hold a 15–20 min “sync-up” with clients to review deliverable from the previous day and agree on today’s goal, which is decided daily given the client’s priority.
3. the process iterates and stops when the client’s purchased “dev week” is used up.
So we’ve changed from a spec-based to a time-based approach, but not just by selling hours, but by selling prioritized development cycles. This addresses the above three problems:
1. Unclear Spec: no problems as the spec will get more clear as the project progresses.
2. Communication Gap: while it still happens, its effect is at most one day due to daily feedback.
3. Changing Spec: no questions asked at all! As we assume by default, the spec may change daily.
The effects have been amazing.
We delivered and launched the alpha version of Joint Commonwealth Fund (JCF), a crypto index fund, with most basic functions such as smart contract, token purchase, and basic re-balancing in three months with two developers. A more traditional approach may take twice, if not three times as much time.
Another voting-related blockchain project’s first prototype with smart contract, voting and recording was done in one week, its mobile version was done in another two weeks. We can easily imagine just the first prototype would need at least 2~4 weeks in other settings.
A school’s assignment upload system prototype was done in two months, completed with map-based assignment upload, teacher verification/feedback, and assignment queries. It would take typically half a year for the same system to be done.
We found the approach by trial and errors first, but later realized that the key to this amazing effect is due to the 80/20 rule, or Pareto principle, which states that 80% of the results come from 20% of the causes or efforts.
One key aspect we always ask clients is: “what’s the most prioritized item you’d like to see done TODAY?” and we try to deliver that.
In effect, we’ve been applying the 80/20 rule on a daily basis for software development.
If you think about it, let’s say a project may originally be 4-week in scope, what happens if you apply the 80/20 rule on a weekly basis correctly?
You’d get 80% done by the end of first week. What happens if you re-apply again? You’d get 80% of the rest of 20% done in the second week. So theoretically, if the spec doesn’t change, you’d get 80% + (20% x 80%) = 96% done just by the end of the second week!
Of course life won’t be perfect like this and spec is likely to change or expand by this time. But if the process continues, you’d still get much closer to a finished system by the end of 4 weeks then if you try to do everything “according to schedule/plan.”
That’s the magic of the 80/20 rule! And I’d encourage you to think about how it can be applied to your work or project. Please share your experiences and feedback!
If you’d like to learn more, please check out our site to learn more.
