This is the 'share' link to share or bookmark sites. The list can be changed as required.
Monday, July 20, 2009
Sample blog with Twitter widget and Share links
Sample blog with Twitter widget and Share links
This is the 'share' link to share or bookmark sites. The list can be changed as required.
This is the 'share' link to share or bookmark sites. The list can be changed as required.
Friday, March 28, 2008
80-20 rule and Time Management Matrix for Software Development productivity.
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.
Thursday, February 21, 2008
Is Agile really Agile?
Staying updated with technology and industry jargons is like surviving in a dog eat dog world. One such industry jargon is ‘Agile Development Methodology’. It’s been around for a while now but how safe is it to say that you confirm to the methodology and follow all the Agile principles?
From a software developer’s perspective, we’ve come a long way from the dinosaur days of cutting endless pages of code with a ‘heavy-weight’ or no development methodology at all. What’s hard to believe is that those days were just around a decade ago.
Agile principles evolved from this need to make software lighter, faster and more people centric.
I’ll save you the trouble of Googling “Agile” and looking for Wikipedia’s definition by quoting them here:
“Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project”
This blog discusses why Agile Methodology is good for your software’s health but how improper use can make it toxic. If any of my opinions seem too biased, they are probably true. :)
But anyone who has read so far probably knows what my rant is all about and for those who don’t, this could be extremely enlightening or more likely, a total waste of time.
“Agile is a beast with a Multiple Personality Disorder.”
What the hell is he talking about?? Well, I call it a beast because of its enormous potential to be effective; however some of its principles are adaptive and should not be implemented too literally.
For example consider Scrum, an agile process to manage and control development work that is widely adopted by the gaming industry. Scrum suggests 15 minutes daily meetings to discuss the progress from the previous day. This could be an excellent way to manage work and timelines of an average size team. However a project running across 2 or more countries with developers working on different modules may not reap the benefits.
Consider Pair Programming, a practice of Extreme Programming (XP) which is also an Agile process. Whoever thought of this concept had a wicked sense of humour. Having two cranky programmers (no offence intended, I can be one at times) breathing over each others necks (and correcting the others code) is no less entertaining than watching Tyson and Holyfield head-butting with no referee.
Fine, that’s a bit over the top especially while there are serious developers who swear by the concept and at this point are seriously swearing at me. There are endless benefits of pair programming when used in the right environment but the question you need to ask is; how do I make it work for Me? And the answer is quite simple.
“Don’t adopt Agile, but let Agile adopt you”
Agile principles work well when the requirements are constantly changing; when frequently delivering an evolving product is essential to satisfy the customer; when business stakeholders are easily accessible for face-face communication; when the measure of success is having a working product that the user has accepted; when teams and developers are self organised.
But in the real world things can be quite different. In some cases large teams of developers may exist; Stakeholders may be located all over the world and won’t be available for frequent communication; Products that are mission critical may not need much user involvement but need to be reliable; and so on. So what happens when this sounds like your environment and you still want to be Agile?
“When the only tool you own is a hammer, every problem begins to resemble a nail.” – Abraham Maslow.
Now he’s quoting famous people but what does he mean? Think about Agile as a toolbox and not as one single tool. Pick only the tools that you need for the job and leave the others alone. In other words, look for the Agile features that are relevant to your systems, adopt the ones that you can mould into your activities and ditch the ones that just don’t fit. The secret is in knowing how agile one needs to be. This link pretty much summarises when to not use agile.
In conclusion, I say go ahead, indulge and be agile. Your systems and activities will only get better and well organised but make sure you know when to stop.
From a software developer’s perspective, we’ve come a long way from the dinosaur days of cutting endless pages of code with a ‘heavy-weight’ or no development methodology at all. What’s hard to believe is that those days were just around a decade ago.
Agile principles evolved from this need to make software lighter, faster and more people centric.
I’ll save you the trouble of Googling “Agile” and looking for Wikipedia’s definition by quoting them here:
“Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project”
This blog discusses why Agile Methodology is good for your software’s health but how improper use can make it toxic. If any of my opinions seem too biased, they are probably true. :)
But anyone who has read so far probably knows what my rant is all about and for those who don’t, this could be extremely enlightening or more likely, a total waste of time.
“Agile is a beast with a Multiple Personality Disorder.”
What the hell is he talking about?? Well, I call it a beast because of its enormous potential to be effective; however some of its principles are adaptive and should not be implemented too literally.
For example consider Scrum, an agile process to manage and control development work that is widely adopted by the gaming industry. Scrum suggests 15 minutes daily meetings to discuss the progress from the previous day. This could be an excellent way to manage work and timelines of an average size team. However a project running across 2 or more countries with developers working on different modules may not reap the benefits.
Consider Pair Programming, a practice of Extreme Programming (XP) which is also an Agile process. Whoever thought of this concept had a wicked sense of humour. Having two cranky programmers (no offence intended, I can be one at times) breathing over each others necks (and correcting the others code) is no less entertaining than watching Tyson and Holyfield head-butting with no referee.
Fine, that’s a bit over the top especially while there are serious developers who swear by the concept and at this point are seriously swearing at me. There are endless benefits of pair programming when used in the right environment but the question you need to ask is; how do I make it work for Me? And the answer is quite simple.
“Don’t adopt Agile, but let Agile adopt you”
Agile principles work well when the requirements are constantly changing; when frequently delivering an evolving product is essential to satisfy the customer; when business stakeholders are easily accessible for face-face communication; when the measure of success is having a working product that the user has accepted; when teams and developers are self organised.
But in the real world things can be quite different. In some cases large teams of developers may exist; Stakeholders may be located all over the world and won’t be available for frequent communication; Products that are mission critical may not need much user involvement but need to be reliable; and so on. So what happens when this sounds like your environment and you still want to be Agile?
“When the only tool you own is a hammer, every problem begins to resemble a nail.” – Abraham Maslow.
Now he’s quoting famous people but what does he mean? Think about Agile as a toolbox and not as one single tool. Pick only the tools that you need for the job and leave the others alone. In other words, look for the Agile features that are relevant to your systems, adopt the ones that you can mould into your activities and ditch the ones that just don’t fit. The secret is in knowing how agile one needs to be. This link pretty much summarises when to not use agile.
In conclusion, I say go ahead, indulge and be agile. Your systems and activities will only get better and well organised but make sure you know when to stop.
Subscribe to:
Posts (Atom)
