The Pareto principle (also known as the 80/20 rule) is a phenomenon that states that roughly 80% of outcomes come from 20% of causes.
Of course it's a loose 80/20, but 80/20 sounds better then 70-90/30-10. The world of a Lowcode developer is a world of the 80/20 rules (and maybe for all developers). And it's not just outcomes to effort, but most aspects of developing.
For a little perspective my area of expertise is in the Power Platform, predominately with Power Automate and Power Apps. I'm well versed in PowerFx (the LowCode language, created by Microsoft for the Power Platform), and I have a history from Excel, to VBA, SharePoint and then JavaScript (learnt for a LowCode app platform called Appery.io), so I think I'm a good example of a Citizen Developer in LowCode.
Throughout my time I see the 80/20 very prevalent in LowCode, and it's a good philosophy to follow:
ProCode-LowCode-NoCode
The sweet spot for LowCode is 20% the complexity of ProCode. Anything above starts to creep towards ProCode, and anything below is definitely more NoCode, often with too much lost functionality.
Value to Complexity
80% of the value of a project often comes from 20% of the complexity. A good LowCode platform will still deliver 80% of the functionality of ProCode, but with only 20% of the complexity.
Getting the right platform for your need is critical.
The Code isn't Everything
LowCode platforms often paint the picture that the coding is the biggest challenge and complexity of a project. But it's actually only 20%, the 80% is everything else you need for the app/automation/bot needs to be enterprise ready - root cause analysis, design, test, environments, ALM, security, audit, documentation, support, platform updates, and much more.
Juice Worth the Squeeze
With most LowCode projects (particularly RPA), 80% of the value/savings will come from only 20% of the project. So focus on the right 20% to get the best return.
The Development Journey
During a user story development you will often experience the 80/20 rule, with 80% of the work done in 20% of the time/effort, and the last 20% taking 80% of your time. As a developer you should always be prepared for the unexpected error that can take days to debug.
Too Many Meetings
If you find yourself working in a team where more than 20% of your time is taken up by non dev/test/build or agile meetings, then you are not being as productive as you should be.
Innovation
Innovation is the key to learning and keeping yourself motivated, if you can get an 80/20 split to business projects to innovation you will be in the right place. It can be Google's approach of 1 day a week on personal innovation projects, or the last sprint of a PI approach, both 1/5, both the right balance.
Failing is OK
We all aspire to deliver 100% of our work 100% of the time, but if we are then are we stretching ourselves. We should be comfortable with occasionally only delivering 80%, as long as that 80% has most of the benefits. We should be pushing ourselves just the right amount to improve and have the confidence to step outside our comfort zone, that can only happen if we know failing is ok.
Follow the Users
With nearly every app, 80% of the users will use only 20% of your app. That doesn't mean we ignore the other 20% of the users, but it does mean our focus should be on the key 20% of your app. You need to know the key features, so that they can get priority (bug fixes, updates,etc).
Listen to Your Uses
80% of your volume will come from 20% of your uses (aka whales). These uses will use the app more, generating the majority revenue/savings. Make sure you listen to them, they should be your testers and involved in writing the requirements.
Skills
No developer knows every function to a language, but they know the key 20%, the other 80% is why we have Google and Stackoverflow 😎
Top comments (0)