Build Times [ctd]

All I can say is wow! I never had any idea that the problem was so prevalent in the .NET space. Over 50% of people had builds ranging over 1 minute! This is a real pain point for development teams (think about your TDD cycle). I can tell you the first thing I would be doing is ctrl+right arrow to get over to my email and twitter to start checking out what is going on. This while seeming inoculate has a major cost associated with it.

I forget what I was working on. I get a push/pop on my mental stack. I also tend to get easily distracted wait shiny thing. This cost is real and can actually be quantified through the use of monitoring software. This is actually a feature we have been looking at building into a plugin (monitoring of users flow to help measure improvements).

I would love to see some discussion on why build times has been prioritized to such a low level on teams. Is it just death march mentality? Is it a frog in a boiling pot? Is it technologies that you use that have notoriously long build times? Is your software actually decoupled into reusable bits?


  1. jamestryand
    Posted February 26, 2012 at 1:32 pm | Permalink | Reply

    From my own experience most large projects have a single build, that’s used by both the developers and the build server itself, with little if any differentiation between the two.

    The reason for not splitting these is given to be that the dependencies thoughout the project are nested in such a way as to make this infeasable, or that it’s more convenient to have the lot available at a time.

    my 2c

  2. Posted February 26, 2012 at 6:41 pm | Permalink | Reply

    It’s the “monolithic build” syndrome. Like many other types of technical debt it’s usually not prioritized.
    A kind of “irrational escalation”

  3. pwistrand
    Posted February 26, 2012 at 6:49 pm | Permalink | Reply

    I think I’m still to jaded by the experience to be talking about it, but here goes. I was working on a project where the upstream build took in the region of 45 mins and the downstream build 30mins. Not helped or course by running on virtual machines. Eventually even the eternal of all optimists agreed that something had to be done and the build was finally broken apart after allot of planning. After that most builds took in the region of 5-6 minutes exclusive of the time for dependency builds. From memory I think there was somewhere in the region of 250 projects across around 90 solutions for what constituted the product in the end before I moved on.

    The problem wasn’t in the design so much as in the team culture to let it get that bad. As much as we might think a few minutes is pushing the limits there will always be someone who thinks there is nothing wrong with the status quo and pointing at the build is just looking for problems that don’t need to be solved. If there isn’t collective agreement these things don’t get fixed.

  4. Steve Sheldon
    Posted February 27, 2012 at 4:41 pm | Permalink | Reply

    The more complex and bigger it is, the more important you are… right?

  5. Pascal Laurin
    Posted February 27, 2012 at 5:36 pm | Permalink | Reply

    A previous team I worked with believed that the only way to control dependecies in the solution was to create a lot of small projects (10-15 classes max) so they ended up with 180+ projects for less than 80k LOC total. The build on a really fast machine was around 1m15s.

    Another project I worked on before that we had a 600k LOC solution in 7 projects (including test projects and organized for deployment) building in around 8 seconds on an average machine.

    The more projects you have the slower the build. Take a look at some of Patrick Smacchia posts on CodeBetter for more information.

    • Posted February 27, 2012 at 6:26 pm | Permalink | Reply

      This is true. Though projects are not the only mitigating factor.

  6. jamestryand
    Posted February 28, 2012 at 9:32 pm | Permalink | Reply

    we use VSS (and my previous place CVS) – build time doesn’t factor highly for most people as they have other, more pressing build issues to contend with…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: