Local Build... how big and how long?

Peter Morlion raised an interesting topic on the Agile Alliance LinkedIn group about how long a developer build should be allowed to run. It seems his team is split down the lines of "its important, so suck it up" and "this delays me too much, make it better".

His full question was:

Local build takes a while - run a stripped-down version?
Like in a lot of teams, we update from the source repository, change code, run the build locally, and commit if it builds. So far, so good. But the build takes a while of course. Personally, I think that's just something to live with, but my teammembers want to use a stripped down version of the build (mainly not building the sandbox, because it doesn't change much).
What is your opinion on using a non-complete build before committing, while the build server still runs the full build?

As one of the first to answer I said:

I would agree with your team members... unless I already need to take a smoke break every hour or so, that does not enable higher productivity. ; )

In my last team, the local build included the tests... If your developers have to wait more than 2 minutes for the process to complete, they start seeing this time investment as an impediment and may try to work around it by coding larger chunks before committing and integrating. This is the reverse direction agile maturity typically should take a team (especially a team leveraging TDD).

The sooner someone can verify something in the integrated build server, the better off the team will be. The purpose of the local build is to smoke test the local and obviously connected things they are focused on.

A balance has to be created between the two. If you swing too far in the other direction, then the team is hurt because the integrated build is broken more often.

Good luck finding the happy medium.