The 80 / 20 rule for software developers
The Pareto principle also known as the 80/20 rule assumes that 20% of the efforts yield 80% of the results.
This is a concept that can be applied in almost all aspects of life but is a more common principle in business. But what does this have to do with software development?
Well as I mentioned the 80/20 rule can be applied almost everywhere that means to software development as well. According to a study users use regularly around 20% of the apps features while a good 45% is never used. What does that mean for developers? That most of the work will eventually get tossed away.
What can we do about it?
One of the most important steps you can take as a developer building applications is identifying which features require the most attention, then distribute the time according to the importance of each feature.
This is easy in theory but harder in practice, in the heat of the moment you always want to make every feature perfect because that’s what the “best developers do”.
Instead of striving to become the “best developer” become the most efficient developer. Become the developer that delivers the 80% of the work in the 20% of time. Remember the reason you started and which features you had in mind when you started because they will probably be the ones that need the most attention.
If possible, continuous testing and analytics would yield the best results. Get in contact with your users (if possible) and see what they want and what they don’t, then be agile and move your efforts according to your users wants.
A case study
When we first started Troosh we knew we wanted a platform where users could improve their skills interactively and in groups.
Our primary focus was the implementation of group projects. So first we built a very quick basic app foundation to get things rolling and then started our implementation.
After some trial and error we came to a pleasing result.
We were able to dish out a great chunk of functionalities just for this one feature.
Some of these include:
- Mentor can link resources to this project. Teams can later see these resources collectively on the project page.
- Dynamically adding users to teams.
- Real-time notifications for task completion for both users and mentors.
- Optional prerequisites for users to know before joining this project.
- Ability to chat privately with your team or with your mentor.
- Feedback provided by the mentor for each task completion.
- Awards given per task or project completion. This gives teams a sense of reward along with what they learnt through the process. They can later show off these awards to their friends!
But wait, there is a lot of other features we need to cover such as user profiles, notifications, posting, settings etc. These also need to be completed for our MVP.
We used a lot of our precious time to implement the group projects and got a great result. Should we spend an equal amount of time for each other feature?
Short answer: No.
Long answer: If we did that a competitor could catch up, we could run out of recourses and worse, spend a tremendous amount of time and recourses on features we think will matter but will actually not matter.
Conclusion
It’s important to distinguish what is important and what’s not when developing new apps. This goes both ways from a business perspective and a developers perspective. Part of a developers job is to also think what is needed from the business perspective.
One of the worst feelings as a developer is throwing features away that you took the time and effort to develop and hope they turn out perfect.
So it’s important for your own sanity and to avoid burnouts that you don’t spend extra time on unneeded features.
Look forward for more of our implementations and more behind the scenes info on how we build Troosh!
