Why Software Builds Fail 279
itwbennett writes: A group of researchers from Google, the Hong Kong University of Science and Technology and the University of Nebraska undertook a study of over 26 million builds by 18,000 Google engineers from November 2012 through July 2013 to better understand what causes software builds to fail and, by extension, to improve developer productivity. And, while Google isn't representative of every developer everywhere, there are a few findings that stand out: Build frequency and developer (in)experience don't affect failure rates, most build errors are dependency-related, and C++ generates more build errors than Java (but they're easier to fix).
Re:Because I'm lazy (Score:3, Interesting)
When in CS, I had a prof that had one rule that for release (not beta/alpha/dev) code, if the code had even a single warning, it was unshippable unless there was an extremely good reason (which would be part of the README) of why it happened. Yes, this was a PITA, but he was trying to teach something that seems to have been lost.
Re:Because I'm lazy (Score:3, Interesting)
The problem is that sometimes that's not an option. For instance, a few weeks ago I was working with some code in VS 2010 that used named enums. Even though Intellisense was smart enough to recognize the enum without the explicit name ("enum" instead of "name::enum"), the compiler kept throwing "unknown symbol" errors if the enum was left as-is, and it would throw a warning indicating that the syntax given was only valid under C++11 if I explicitly scoped the enum, which failed the build because we compile with warnings equating to errors. Changing the enum itself to be enclosed in a class or at least a namespace probably was the right way to do it, but it would end up affecting a lot of other code, which in turn meant an extra regression pass for the QA guys. So, the only practical solution at the time was to disable the warning for that block of code, and re-enable it afterwards with a comment explaining the reason.