I've been thinking about "dead time" a bit since I sent this posting. This would not be
a simple phenomena to detect and measure!
From the raw data standpoint, I think we're in pretty good shape. One way to proceed
would be to determine the potentially time-consuming tasks (compilation, local builds,
unit testing, CVS checkins/outs, continuous integration builds, etc.) and then provide
DevEvents with a "start-time" and "end-time" properties whose values are time-stamps.
This needs to be combined with some kind of dependency model, that helps us to represent
the "development cycles" noted in the article. Of course, this needs to be configurable
on a project-by-project basis. Hongbing's SDSA mechanism might be appropriate
infrastructure.
It would also be nice to be able to visualize the cycles and the lengths of their
components. The Timeline system I noted earlier comes to mind as a particulary cool way
to do this.
Finally, telemetry would be a great way to see how the dead time ratio is changing over
time.
Cheers,
Philip
--On Wednesday, November 08, 2006 11:11 PM -1000 Aaron Kagawa <[EMAIL
PROTECTED]> wrote:
Interesting. Sounds like more Stream Analysis for Hongbing.
If Hackystat can analyze your development cycles (it sort of does this already
with the
TDD analyses) we can open a new area of Personal Development Process analyses.
Something, which I still think is lacking in Hackystat. I would like to learn
more
about how I program and what my tendencies are when fixing a bug, adding a
feature, etc.
Maybe I build too often, causing more dead time and cuts down my flow! Haha.
thanks, Aaron
At 11:07 AM 11/8/2006, Philip Johnson wrote:
Here's an interesting article about the "dead time ratio":
<http://www.oreillynet.com/onjava/blog/2006/03/dead_time_code_compile_wait_wa.html>
Kind of related to sixth sense software's 'flow time', but actually
measures something closer to the reverse!
Cheers,
Philip
