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:It's usually a computer problem (Score:5, Insightful)
Dependencies? (Score:3, Insightful)
Dependencies just magnify all other problems. If your code depends on nothing then it won't break unless the compiler changes. Unfortunately such programs don't exist because you can never depend on nothing and do anything useful. In reality if you depended on nothing you'd end up writing your own console, your own I/O, pretty much your own CRT. This sounds great until you realize your dependency is now the hardware itself and it's likely your code won't be portable in any useful sense. That's why we have kernels.
The problem with C++ is that dependency management is usually file-level and developers 'rarely' care about any file-level constructs (and nor should they, it's an abstract packaging concept). As a result you try to drag in one enum and end up with 100 #includes and 500 new classes you don't care about. This causes bigger object files to be emitted, vastly slower linkage and lots of dependencies you don't expect. All it takes now is for one of those includes to #define something unexpected and BOOM...the house of cards comes crashing down.
Also, did I mention? The C preprocessor causes a lot of grief when it's abused.
Dependencies Problems = "It builds on my machine" (Score:5, Insightful)
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 (Score:4, Insightful)
Re:It's usually a computer problem (Score:5, Insightful)
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:Here's a concept to prevent this crap - UNIT TE (Score:2, Insightful)
Why not just say that you should always build against the latest official working source before checkin? It has nothing to do with unit testing.
Re:Because I'm lazy (Score:5, Insightful)
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 (Score:5, Insightful)
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.
Re:Because I'm lazy (Score:4, Insightful)
You should be compiling with warnings as errors as soon as you start coding, and you should fix each one as they occur before you move on to write the next line of code.
Putting off fixing these problems leads to bloated and fragile code and wastes much more time debugging and fixing later.
What you should be doing outside the CS class and in the so-called "Real World" is "being productive". That usually means screw the warnings, it has to be completed ASAP or we'll find someone "more productive" than you are.
why women don't code also a solution (Score:5, Insightful)
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:
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
Re:Because I'm lazy (Score:4, Insightful)
Why is one reason why no one should ever use Microsoft's code or tools as exemplars. I've got a theory that the first thing Microsoft has a new intern do is write example code to give to customers, and the second thing the intern is asked to do is read the coding guidelines.