The 80-20 rule or Pareto’s principle is a well known Management technique that has been successfully used to improve business productivity. The beauty of this rule is its simplicity and its use in everyday life scenarios. Once you identify the 20% of your activities that take 80% of your time and efforts, you can work on reducing or reversing the trend. We can apply the 80-20 rule to almost everything we do; 80% of the time you wear 20% of your clothes or shoes. 80% of your income comes from 20% of your clients.
It came as no shock to me that our software development team spent 80% of the time fixing bugs and only 20% on creating new code. This may be an accepted trend in the software development industry but fortunately there are ways to change this ratio and improve software productivity.
Set aside 20% of your day.
Most organisations use a system to record all the bugs and issues. If you don’t use such a tool get your hands on one. If you really can’t get one, maintain a diary with all the bugs that need fixing. The next step is to allocate 2 hours of your day to fix bugs. Yes you read correctly- just 2 hours, which is around 20-25% of an average work day. The first 2 hours of your work day are best so you have the rest to create new code. Ok, realistically speaking a developer works much more than the average 8 hours and 2 hours won’t fix all the issues in the system.
I can explain how you can apply a few basic techniques and make this work for you. These ideas are based on Stephen Covey’s Time Management Matrix which helps you organise your time effectively.
If it’s not urgent and important, it can wait.
In the issues management system or your bug diary, allocate every entry one of these 4 priorities:
1. Urgent and important
These are issues that break the system’s workflow and the user cannot proceed with critical work. Your users will make every issue sound urgent and all issues may seem to fit this category, but the secret is to identify how important it is for the application. If it improves efficiency of code or has the potential to reduce future bugs and is critical to the workflow, then it falls in this category.
2. Not urgent but important
This quadrant should have issues that are not urgent but are important from the code efficiency point of view. For example adding a feature to a custom control can improve efficiency to various screens in the system. Reports are important to summarise data but not always urgent. Our aim should be to try and reduce the size of the first 2 quadrants. If the user says that something is urgent find out if it is important and what would go wrong if it’s not fixed soon. By doing this you can identify which ones can be pushed to quadrants 3 or 4.
This quadrant should have issues that are not urgent but are important from the code efficiency point of view. For example adding a feature to a custom control can improve efficiency to various screens in the system. Reports are important to summarise data but not always urgent. Our aim should be to try and reduce the size of the first 2 quadrants. If the user says that something is urgent find out if it is important and what would go wrong if it’s not fixed soon. By doing this you can identify which ones can be pushed to quadrants 3 or 4.
3. Urgent but not important
The urgent issues that are not so important for the application’s health fall in this category. At times senior project stakeholders request things that do not add value to the application. These may still be urgent and need to be taken care of.
The urgent issues that are not so important for the application’s health fall in this category. At times senior project stakeholders request things that do not add value to the application. These may still be urgent and need to be taken care of.
4. Not urgent and not important
The last quadrant is self explanatory and it obviously should be avoided as much as possible. It is surprising how many times we try to fix these issues because it may seem easy or the person who requested it is your buddy or was very polite. They are polite because they want you to do something and they surely won’t mind waiting if it’s not urgent or important.
Now that you have allocated the priorities, spend 80% of your 2 hours (1.5 hrs) on quadrants 1 and 2 because these are important and by focusing on them you are improving the efficiency of your code. Spend the remaining 20% (30 mins) on quadrant 3 which is not so important but is urgent. Avoid anything that is in quadrant 4 as much as possible. Work on these issues only if they escalate and become urgent or you have no other bugs to fix.
You don’t have to be too rigid with the percentages and time that you allocate to tasks. 80-20 can be 70-30 and 2 hours can extend to 3 in a day as long as you focus more on important issues.
Following this simple technique will help you spend more time focusing on the essential things and in turn help improving the productivity of your entire software system.
The last quadrant is self explanatory and it obviously should be avoided as much as possible. It is surprising how many times we try to fix these issues because it may seem easy or the person who requested it is your buddy or was very polite. They are polite because they want you to do something and they surely won’t mind waiting if it’s not urgent or important.
Now that you have allocated the priorities, spend 80% of your 2 hours (1.5 hrs) on quadrants 1 and 2 because these are important and by focusing on them you are improving the efficiency of your code. Spend the remaining 20% (30 mins) on quadrant 3 which is not so important but is urgent. Avoid anything that is in quadrant 4 as much as possible. Work on these issues only if they escalate and become urgent or you have no other bugs to fix.
You don’t have to be too rigid with the percentages and time that you allocate to tasks. 80-20 can be 70-30 and 2 hours can extend to 3 in a day as long as you focus more on important issues.
Following this simple technique will help you spend more time focusing on the essential things and in turn help improving the productivity of your entire software system.
