Pomodoro And EBS: Two Classical Techniques To Measure A Developer's Productivity
Pomodoro and EBS (Evidence Based Scheduling) can be useful to both employers and freelancers (or even regular employees). A project is composed of a number of milestones, and a milestone is composed of a number of tasks.
Simply speaking, both tools aim to measure how long a developer or programmer takes to complete a certain kind of task (such as front-end design, coding, unit testing, etc).
This information can then be used to estimate how long a certain kind of project will take for that programmer to complete. Conversely, it can also be used to fix the financial cost of the project and/or the general hourly rate of that programmer.
The first one, Pomodoro, developed by Francesco Cirillo in late 1980s is simple and ingenious in execution. As per this technique, a programmer works for 25 minutes on a task, then takes a break which can last from 5-15 minutes (its encouraged to take short breaks frequently and then a long one after a certain interval).
It can be customized to one's schedule and many variations of this method exist in various productivity apps, perhaps the popular time-tracking app, Toggl also uses a variation of this technique.
Coming to the point of measurement, the app can be adapted to measure the programmer's productivity, provided:
1. Each task is associated with a tag like "PHP coding", "Python coding", etc., and a grouping like "low complexity", "medium complexity", etc.
2. Reports are then calculated based on the time it takes for a certain programmer to complete a task of a certain tag in a given grouping (complexity).
A few months ago, I'd myself attempted to develop this kind of app using Python. Its a console based app with limited features which I'm thinking of turning into a Flask based web app as a side project!
I'd read about this technique on the Joel On Software blog and found this method quite fascinating! This technique is based on the premise that not only each coder, but each skill is also different in its own way, a different time complexity. According to Joel, you need to be spending your time on that skill which provides you maximum financial return, and you can't know what skill it is unless you have a measurement technique (Evidence Based Scheduling):
Joel also believes that most programmers simply hate to make schedules, because firstly, its not fun and secondly, they aren't realistic. With this premise, Joel & Co. decided to automate the whole thing into a system or an app that runs on a programmer's desktop so that even the most grouchiest of developers can work with it! They call this proprietary software EBS (Evidence Based Scheduling) because its result are based on historical evidence (perhaps using similar techniques like tagging and grouping them for technology labels and complexity as I described earlier, or something similar).
Once the system or app has the historical average time for a certain kind of task by one or more programmers, its easy for the app to estimate the time for another project or milestone of similar complexity. Now, that next project may vary a bit from the app's estimate, so the app can evolve and provide future estimates as probabilities instead of an exact time duration! Statistical techniques like correlation and regression analysis can be used to come up with an estimated future completion date for a given project.
This is how EBS works but there are other productivity apps too that work on this same principle.
Simply speaking, both tools aim to measure how long a developer or programmer takes to complete a certain kind of task (such as front-end design, coding, unit testing, etc).
This information can then be used to estimate how long a certain kind of project will take for that programmer to complete. Conversely, it can also be used to fix the financial cost of the project and/or the general hourly rate of that programmer.
Pomodoro Technique
The first one, Pomodoro, developed by Francesco Cirillo in late 1980s is simple and ingenious in execution. As per this technique, a programmer works for 25 minutes on a task, then takes a break which can last from 5-15 minutes (its encouraged to take short breaks frequently and then a long one after a certain interval).
It can be customized to one's schedule and many variations of this method exist in various productivity apps, perhaps the popular time-tracking app, Toggl also uses a variation of this technique.
Coming to the point of measurement, the app can be adapted to measure the programmer's productivity, provided:
1. Each task is associated with a tag like "PHP coding", "Python coding", etc., and a grouping like "low complexity", "medium complexity", etc.
2. Reports are then calculated based on the time it takes for a certain programmer to complete a task of a certain tag in a given grouping (complexity).
A few months ago, I'd myself attempted to develop this kind of app using Python. Its a console based app with limited features which I'm thinking of turning into a Flask based web app as a side project!
Evidence Based Scheduling
I'd read about this technique on the Joel On Software blog and found this method quite fascinating! This technique is based on the premise that not only each coder, but each skill is also different in its own way, a different time complexity. According to Joel, you need to be spending your time on that skill which provides you maximum financial return, and you can't know what skill it is unless you have a measurement technique (Evidence Based Scheduling):
You want to be spending your time on things that get the most bang for the buck. And you can’t figure out how much buck your bang is going to cost without knowing how long it’s going to take. When you have to decide between the “animated paperclip” feature and the “more financial functions” feature, you really need to know how much time each will take.
Joel also believes that most programmers simply hate to make schedules, because firstly, its not fun and secondly, they aren't realistic. With this premise, Joel & Co. decided to automate the whole thing into a system or an app that runs on a programmer's desktop so that even the most grouchiest of developers can work with it! They call this proprietary software EBS (Evidence Based Scheduling) because its result are based on historical evidence (perhaps using similar techniques like tagging and grouping them for technology labels and complexity as I described earlier, or something similar).
Once the system or app has the historical average time for a certain kind of task by one or more programmers, its easy for the app to estimate the time for another project or milestone of similar complexity. Now, that next project may vary a bit from the app's estimate, so the app can evolve and provide future estimates as probabilities instead of an exact time duration! Statistical techniques like correlation and regression analysis can be used to come up with an estimated future completion date for a given project.
This is how EBS works but there are other productivity apps too that work on this same principle.
Comments
Post a Comment