Why Software Builds Fail

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).

Comments

Re:It's usually a computer problem

[matthiasvegh]

Oh coding error? Well thats helpful. Misplace a semicolon in a non-trivial meta-program or dsl in C++, and just watch the errors that the compiler spits back at you. None of which, will have anything to do with semicolons. I suppose this is why the C++ errors are considered to be easy to fix. Mistype a word, and you get 15000 lines of errors. I suppose it's easy to fix all those errors too. Yes, but figuring out what exactly the coding error was is kind of the point.

Dependencies Problems = "It builds on my machine"

[Virtucon]

Once code is checked in and goes through the standard build process, that's where this is expected to occur because in my experience it's the local environment where the developer does the coding that's the root problem. Why? Developers don't refresh their build environment because of the potential for other problems it may create. I had one gig to unfuck some code at a company a couple of years ago and found out that in order to set up a Dev environment in this place could take two weeks or more depending on what team you were on. You had to go through a script, download this, install that, change this.. A nightmare. Updating dependencies on a local desktop created panics amongst the developers who were reluctant to ever change anything they had which "was working" because you could spend days trying to fix what was broken. Naturally any time they migrated code into test or production (there was no build system) things failed there because of dependency related issues. Also depending on who the developer was, they naturally felt that bypassing the Test/QA cycle was a job perk.

I found dozens of dependencies on desktops that were out of date, deprecated or had major vulnerabilities and that went for the production systems as well. It was bad all the way around from a best practices perspective. Daily production crashes were the norm, the VP of Dev had a monitor on his desk so he could "troubleshoot" production problems it was that bad.

Yes there's shops like this that are still out there.

Re:It's usually a computer problem

[aliensexfiend]

When I see the error avalanche the first place I check are the first few error messages and that is usually enough to spot the problem. Typos still make c++ compilers barf way too much crap.

Re:It's usually a computer problem

[Anonymous Coward]

Please, give up the C++ slander.

Like any compiler output, read the first error. If you are a developer of any calibre, having a few pages of errors shouldn't phase you and it's not unique to C++ to generate a few erroneous errors. All it requires is a basic level of competence and if you don't possess that then any programming
language that facilitates you generating anything that compiles is doing noone any favours.

Re:Because I'm lazy

[geekoid]

NO, he was teaching engineering practices, and a good one.

People like you is why software is in such a terrible state as an industry.

Re:Because I'm lazy

[EvanED]

I'm a fan of warnings as much as the next guy, but there are plenty of times that's not practical. Even if you accept nothing else I say, there are plenty of times where third party code (say, for example, Boost...) has warning-producing stuff in it. Do you fix it and maintain your own branch? Submit it upstream, hope it gets accepted, then wait a month for the new release, then demand everyone upgrade to the latest bleeding-edge? That's often (maybe usually) not feasible, which means it should probably just disable it. Fortunately, GCC finally got around to adding #pragmas that sometimes let you disable and re-enable warnings for just the offending headers.

But beyond that, there's also a reason that compilers have most warnings off by default. And why -Wall doesn't turn on anything close to all warnings. And why even -Wall -Wextra isn't all warnings. Because there's a gradation of false positive/false negative tradeoffs, and what's appropriate for you isn't appropriate for everyone. Do you really compile with all warnings, or do you suppress some? Because I can almost guarantee it's the latter, even if you're suppressing them through inaction.

why women don't code also a solution

[globaljustin]

I know this is "offtopic" but stay with me and I'll bring it around on-topic...

A big question that people are throwing Billions of dollars & millions of internet comments about is "How can we get more women into programming/coding?"

Ok...b/c our industry is by default very complex, it's not unreasonable that to really drill down to an answer to that question might be fairly complex...the answer can be summarized, sure, but to really get at the problem it involves learning a bit.

Here, in this thread, we find out why...and it affects us **all** not just woman coders, or coders...it affects how the whole company works and the perception of value...witness:

Why do you assume all warnings are useful?? Some of the compiler warnings are just pedantic and are "noise" such as "variable declared but not used", etc.

There is a balance between no warnings and pedantic warnings, namely the useful ones.

One of the things that's nice about the Eclipse IDE is that you can select the importance of selected messages, all the way from "ignore" to "fatal", depending on shop standards and personal paranoia.

However, the offline builders such as Maven and Ant cannot adopt those preferences, so it's not uncommon for a production build to spit out dozens or hundreds of warnings about things that don't actually matter.

Working with C/C++ I almost never had clean builds, since even....

Here we have a central thesis:

"There is a balance between no warnings and pedantic warnings, namely the useful ones."

Parent agrees, and describes how using a **proprietary software** (Eclipse) which adds an **extra abstraction layer** to an already ridiculous process...a process which we all know theoretically should be able to be done on a text editor

the fact that coding, the act of developing, software engineering, the 'real work' has such obtuse solutions, solutions to problems based on...

PEDANTIC choices...overkill...the lack of discretion...there are many reasons for this but that's another rant

it's alienating to new people regardless of gender...the only reason many people work jobs as coders is **for the money**

until we address these fundamental issues, the problems that arise only because some compiler programmer was overly pedantic due to lack of empathy skills will destroy any attempt to get non-traditional types into coding

right now, you basically have to be a bit autistic, or be able to think that way on command, in order to code...part of it is genetic, but part of it is deliberate...you have to train your mind to think in a "code" instruction manner...why would a woman do all this given other options?

the solution to pedantic, tone-deaf coding choices is, of course, a fresh perspective that can help get rid of problems from abstractions...

we need women in coding to help make coding more appealing to women

so, to make this on-topic, I think **more women in coding** is a long-term solution to problems in TFA