Richard Cownie (tich@pobox.com) on 6/28/10 wrote:
>
>I just think that right now, and for the foreseeable
>future, the "critical resource" is developer time, not
>cpu time.

Agreed. However, long compiles are often a huge drain on
developer time. Fast turn-around time from making a change
to having compiled it and done targeted tests on it can
be a huge deal in being a happy developer.

And no, compile farms are not necessarily the answer. They
easily get bogged down. A fast workstation is certainly
worth it, obviously, but if the build time is not good on
a high-end workstation, there's likely something wrong with
the project.

IMNSHO, a compile farm should primarily be used for things
like regression testing, full test coverage, checking all
the possible configurations etc. IOW, stuff you may want to
do before you publish your changes), not for developers
wanting to compile/test their own changes.

If a small change - that happens to involve changing some
core header file or whatever - causes a developer to have
to go to some compile farm, something is seriously
f*cked up. If you can't have your developers do some basic
development on a laptop at their home or a starbucks, that's
a problem right there.

Exactly because you're penalizing the most important
resource - the developer.

Linus