I will start out with stating the obvious -- "scheduling in software projects is a hard problem". Why hard? Simple ... almost all (simple) scheduling techniques are based on two weak assumptions:
1. We can estimate how long a task will take (minimum time -- maximum time).
2. These estimates are reasonably stable (say for at least 2-4 weeks -- this implies the task specification is sufficiently clear, and the developers have the knowledge+skill and technology to complete the task)
These assumptions are the crux of the problem because we cannot estimate well and task specifications are often fluid. But, there is some good news -- developers often can improve the accuracy of their estimate once they start working on a task (even when it changes a bit), and this estimate gets better the longer they work on a task uninterrupted.
Here is an analogy for why estimation in software development is hard:
"You are asked to translate a sci-fi fantasy book from French to English. But, the author of the French edition does not have a complete story nor has she fleshed out all of the characters fully. She has completed about 50% of the book in French and wants the English translation to start soon, so the publisher can release both books at the same time". Can we estimate how long it will take to complete the English edition? Well, how about if we got 5 English writers to work at the same time? Would you like the job of managing these 5 writers -- and produce a project plan against which you have to give a weekly status update?
The analogy is a tad crude -- but it is about as close to software development reality as it gets.
-----
There is another side to the scheduling story. A vast majority of software development work involves extending and maintaining a software system. Which makes scheduling hard since we never know who will be needed for other higher priority tasks. Why can cause a higher priority task?
Well ... the short answer is: bugs! + meetings (sad, but true) + emotions (random interrupt that will pre-empt all other functions in the brain -- esp. strong in meetings).
We cannot estimate how long it will take to fix a bug easily -- Why?
1. Well the developers have to replicate the bug and find out it is a bug --> It take some unknown quantum of time > 10 minutes (why 10? Glad you asked. Over the years, I identified that it took me, at a minimum, 10 minutes read a defect report -- complain about it being very poorly written -- replicate it -- write up a brief note either acquiring it for investigation, assigning it or closing it).
2. If it is indeed a bug, identify root cause. --> Will take over 10 minutes (why 10 again? Well... one has to check out appropriate version from repository, compile and pray that all goes well, reluctantly run in debugger, find culprit and court martial them, got through a mini-localised-merge nightmare, check-in code with appropriate comment, update defect tracking tool, update time tracking tool, check Facebook, write a comment on Reddit, read twitter updates, complain to the world on twitter about the sad state of the codebase).
3. Integration + Regression testing. --> Pick a number > 1 (trust me -- it will be at least 1 minute).
In a perfect world, it will take a minimum of 21 minutes per defect (maximum or a realistic time to fix and evaluate ripple impacts are completely unknown).
Bugs are relatively easier to work on ... but, "new features" and "requested enhancements" these are a completely different ball game when it comes to estimation. Why? Well, since we now are entering the world of "serial meetings" and "wonderful emotions". It is sufficient to say that even the most trivial enhancement is likely to translate into a time quantum > 1 person hour/feature (really? minimum of 1 hour? Well the tasks will involve at a minimum -- thinking/spec + analysis/high-level design + programming + unit test + merge + integrate + regression test + emails + release notes + discussions + arguing why the feature is a good idea + arguing why the feature is a dumb idea + complaining to the sales/marketing team that they should ask before selling a dumb idea + staring blankly at the walls).
----------
Alright .. so estimation is hard, which makes scheduling difficult. So, why bother? Why should one even attempt this? If you are still reading .. thank you for hanging in there. Here is the reason....
We create a plan in order to "prepare the development team" and only hopefully to follow it (i.e. sticking to the plan is a bonus and can happen if the stars are all aligned in the right quadrant of the sky). The entire exercise helps the team consider the issues involved and you are very likely to get the "minimum time it will take" reasonably correct. My experience is that the "minimum time" gives the clients a sufficiently large heart condition.
I find planning exercises are useful if the team collaboratively develops it and reflects on it regularly (every 3-4 weeks works well in my experience). It improves productivity (indirectly), helps team communication a bit better (at least you know what is going on), and allows the team to get a big picture overview and provides some sense of the business drivers/pressures.
However, the fastest way to kill morale and productivity in the development team is to actually force them to stick to some "schedule" that was developed early in the project life cycle by the "all seeing management".
No comments:
Post a Comment