Yeah, other than that book, I don't buy anything from them. Most of their stuff is outrageously priced (but most of their customers are corporate executives).
Let me know if I can help you with anything. I saw the edits to this in RSS, but don't seem to see them here - the measure of the "two minute rule" is how long it takes something to work through a GTD system, not necessarily how long it takes you to call something "brief."
Re: estimating time - this is a strange requirement of planning in just about any system you or a business could use. It's odd to have to estimate how much time something will take, but it's a useful skill to have in the long run. I don't know with any precision how long any piece of code will take either, but I know that with all steps included (requirements, design, development, testing, documentation, production, etc -- assuming the waterfall model), that I can write ANSI C in 1.6 lines of code per hour, Perl in 3.0 LoC/H, and Ruby in 2.4 LoC/hour. You won't need hard-and-fast metrics for this, but a rough ballpark is good.
David Allen Company
Let me know if I can help you with anything. I saw the edits to this in RSS, but don't seem to see them here - the measure of the "two minute rule" is how long it takes something to work through a GTD system, not necessarily how long it takes you to call something "brief."
Re: estimating time - this is a strange requirement of planning in just about any system you or a business could use. It's odd to have to estimate how much time something will take, but it's a useful skill to have in the long run. I don't know with any precision how long any piece of code will take either, but I know that with all steps included (requirements, design, development, testing, documentation, production, etc -- assuming the waterfall model), that I can write ANSI C in 1.6 lines of code per hour, Perl in 3.0 LoC/H, and Ruby in 2.4 LoC/hour. You won't need hard-and-fast metrics for this, but a rough ballpark is good.