--On Saturday, September 10, 2005 1:36 AM -1000 Austen Itsuji Ito <[EMAIL PROTECTED]>
wrote:
Tonight I was thinking about how long Hackystat takes to build locally,
(I think Professor Johnson did something to me so that I would think
about Hackystat on a Friday night) and was wondering how the ant build
sensor collects data. I know that Hackystat collects data on how many
times you invoke a build, but does the sensor collect information on how
long the build takes?
Yes, it does!
The reason why I am asking this question is because I was wondering how
much of Julie and my time was spent waiting for the build process to
finish before we actually test our changes. I wanted to see how much
time was spent building/testing as compared to earlier hackyInstaller
development where changes could be tested immediately in Eclipse.
This is a very interesting question. Cedric, this would seem to be an interesting
telemetry stream. You would want to chart not the aggregate build time (i.e. how much
total time was spent building), but rather the *average* build time.
I know that lots of time is saved by integrating hackyInstaller into
Hackystat, but I was just curious to see if our active time was an
indication that we spent 15 hours building and only 5 hours hacking away.
The integration of HackyInstaller into Hackystat was not motivated by saving time
(indeed, it's clear that building HackyInstaller as an integrated part of Hackystat takes
much longer!)
The integration is necessitated by reliability and quality concerns and the expense of
HackyInstaller build efficiency. Maintaining HackyInstaller as a completely separate
module would be extremely difficult. For example, how could we produce separate versions
of HackyInstaller for each configuration of Hackystat (so that HackyInstaller would
always contain the exact set of sensors associated with a given configuration? For
example, Hackystat-HPC has a different set of sensors than Hackystat-UH, and the set of
sensors associated with Hackystat-UH in version 6.2 is different from the set of sensors
in Hackystat-UH in 6.7.) The only feasible way to make HackyInstaller correct for each
version of each configuration of Hackystat is via integration with the Hackystat build
process itself, and via integrating the installer code into each sensor module.
> I know for a fact that Julie's system would take a very long time just
to run a "ant -q cleanAll quickStart", where my laptop would build much
faster. I believe this was due to my development being done on linux,
where Julie is running Windows XP. If the active time does include how
long a build takes, then perhaps Julie didn't work double my hours ;p
Excellent questions. It would be very neat to be able to show empirically that
developers are more productive on Linux than Windows! :-)
BTW, the issue of build time and productivity has come up before in the context of our
work with NASA. In the MDS project, the build times exceeded four hours, with a huge
impact on their process and their productivity. It would actually be very interesting
from a research point of view to study the build times associated with different
developers at different times in development and try to see at what points a change in
build time makes a difference to the process. For example, I assume that if a build time
is between 1 second and 10 seconds, people basically view it as "instantaneous" and
simply wait for it to complete. Also, they might build very frequently since it is
essentially "free". If a build takes, say, 5 minutes, then they might context-switch,
but might still build frequently, although it is no longer "free". If a build takes,
say, 20 minutes, then they will definitely context-switch, or perhaps change their
process to build less often, because now the build starts to be "expensive". If a build
takes, say, four hours, then they might change their process to start _avoiding_ builds
entirely, because the build is now prohibitively costly.
Thanks and sorry if the question I am asking has been brought up before.
No need to apologize. Each time we visit (or revisit) an interesting question like this,
new ideas and insights come up.
Cheers,
Philip
