Re: Chess Timer
A friend recently posted about using a chess timer in software development. This is my argument against the conceptual need for it.
The main reason stated for the timer is to indicate when development has had to stop on a project due to needing external events to occur, those events could range from a decision being required to something being signed off to requiring a piece of information.
It is stated by the writer to his own admission that he is bad at estimating development timescales and I believe this is the problem here and why the timer is required.
If you can’t estimate your own timescales then how do you organise your workflow and the workflow of people around you? Time wasted on waiting for decisions can be massively reduced by knowing your timescales because if you know your timescales you understand the extent of the work you are doing and the key bottleneck points, if you understand them then you can make people aware of decisions that need to be made in advance to when you need them reducing any time waiting for things you require to continue.
This obviously won’t eradicate all wasted time, there will always be situations in the development cycle where unforeseen problems will occur but even these can be massively reduced with correct specification of the work to be done and by keeping a tight iterative process where problems from the previous iteration can be addressed while another iteration is being implemented.
In conclusion I think the timer isn’t required if time is spent at the specification phase to identify as many as the problem areas as possible. Development should then be done in tight focused iterations and most importantly good time estimates are given so that all people in the development are aware of when information is required.
Cheers for responding to the post- I know it wasn’t my best, I’m a bit out of practice! Good to get back into writing a bit though. Answers inline…
“If you can’t estimate your own timescales then how do you organise your workflow and the workflow of people around you?”
You just take the most important task and do it, until you can’t do it anymore because you require something external. Then you take the next one, etc. Theoretically, ignoring context switching time, this will get you to 100% productivity (you never waste time on anything but what you do best and what you are in theory paid for your abilities in. If you are worrying about other peoples workflow, you are becoming a manager, which is not the most efficient use of your time.
“…if you know your timescales you understand the extent of the work you are doing and the key bottleneck points, if you understand them then you can make people aware of decisions that need to be made in advance to when you need them reducing any time waiting for things you require to continue.”
I guess the fundamental difference in opinion here is that I don’t think you can do anything about the bottlenecks. Other people in the organization just don’t care about your project as much as you do, they have their own problems and priorities. Effort spent persuading them, or worrying or waiting for them to do things, or even planning for them to do things, is again, wasted time- for a developer. The effect of this gets worse the bigger the company. The answer is, in my opinion an active manager who will jump in and take these responsibilities (and a chess timer to tell him when).
I agree with the requirement for an active manager, but I think that manager needs to be informed by his team that information or decisions will be needed before they cause work to stop, that way the manager can have the relevant answers waiting ready for when they are needed. Combine this with what you said about attacking tasks by priority and you should truly be able to achieve 100% efficiency.
When working in a team all members of the team and external parties need to be aware of each others progress and requirements to keep the team as efficient as possible.