> 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.
This function is there, please try this one in the expert interface:
streams MyBuild() = {"desc", "hours",
Build("BuildTime", "true", "[EMAIL PROTECTED]")};
draw MyBuild();
Austen's total build time this year upto today is 6.4 hours, assuming
his sensor is always on.
Cheers,
Cedric
Philip Johnson wrote:
--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
