9

In StackExchange Podcast #09 it is remarked:

Another study recently looked at how much effort goes into maintaining the build system: 5 to 30% of all development effort is spent on maintaining the build system. With the variations being huge even when working on similar projects.

What is the name of the study referenced, and where can it be found? The audio of the podcast contains no further details.

Additionally, does anyone have any links to other studies covering the same topic.

Improve this question
3
  • 3
    Wow. Never crossed my mind that a shop could spend that much time on a build system. We have a hand-made, custom-built build system which does nightly builds of all (20 some) release and (50 some) development branches (if changes have been committed), starts unit tests and stops and starts test servers (one or more per release and one or more for many development branches), mails results etc. Yet in the 4 years that I have been at this employer, I don't think we have spent much more than a couple of man weeks on it and that includes extending the features of our custom-built solution!
    – Marjan Venema
    Sep 6, 2011 at 19:55
  • That's what happens when people refer to something/someone and forget to add the references...
    – wleao
    Sep 6, 2011 at 22:50
  • Don't know the study, but the results may differ depending on what you define by "maintaining the build system". "Is adding or changing files" part of that? Is setting up an installer part of "maintaining the build system"?
    – Doc Brown
    Sep 7, 2011 at 6:08

2 Answers 2

Reset to default
1

I haven't heard the podcast, but the study is probably a paper from the most recent ICSE, called "An Empirical Study of Build Maintenance Effort" by Shane McIntosh et al. Check the Direct link (or the official DOI page if you want metadata).

Their study focuses mostly on how often source code changes impact the build and how many developers on a team are typically concerned with maintaining the build. I remember that it's an interesting study, but I found the numbers a bit difficult to interpret, as is often the case with empirical studies trying to find connections between things :)

Improve this answer
2

I don't have a link for you, but speaking from personal experience, that percentage varies according to 2 main points: 1) system design and complexity 2) and personal organization

A well designed system will require minimun effort to maintain even if it's quite complex. But if your staff is not properly trained and organized in handling the code, you'll probably spend a long time fixing bad builds or wrong commits and the likes...

However, when you have a development environment, Q&A, RC, and Production... It all takes its toll on the process of going from development to actual production.

I would say the percentages are correct, leaning over closer to the 30% mark than 5%. If all you are investing is 5%, you are doing a good job. (This is including errors found during Q&A or RC or even Production due to missmanagement of the Build System, which can cause huge delays).

Improve this answer
2
  • If all you are investing is 5%, I would suggest you are not measuring everything or accurately.
    – mattnz
    Sep 7, 2011 at 0:13
  • no matt. You're using a different definition. Most companies I've worked for have NO build system in place, as in no automated build servers, VCS integration (often no VCS at all except what projects themselves might set up on their own, which ends up under the radar), etc. In any "study" of the percentage of resources used on maintaining the "build system" they'd end up listed as spending next to nothing, unless it were broken down to include the effort spent on maintaining all the ANT and Maven scripts, something rarely done.
    – jwenting
    Sep 7, 2011 at 9:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.