A word about software development

Question

Hello,Below is one of the 26 key principles to guide an agile software development team. Please advise the meaning of "build breakage"Context:Build a culture of immediate response to build breakage. Understand that when the build is broken, it effect everyone in the project, and so there is nothing more important than making sure that the central core code is building and testing properly. I have seen teams that allowed broken tests to persist for months because it was someone else’s job. Everyone suffered, but nobody acted. Instead, there needs to be widespread recognition that a little work will pay back in a big way over the team.Thanks,Best regards,Xin YanChina

Avangi · Accepted Answer

This is probably Pernickety's area, but my understanding is that a given build is similar to a given "version," only more refined.
That is, every time the software is compiled, that would be "a build." A broken build would be one which has ceased to function in some respect.

"Build breakage" would be the occurrence of a failure, or a breakdown, of the software as compiled in a particular build. It would not necessarily be a complete failure, but some aspect of it is not performing correctly.

The phrase, "making sure that the central core code is building and testing properly" seems a little special, but I take "building" here as "being compiled." I'd say that each time new elements are added to the core code, the whole thing must be recompiled; and that would be a new build.
The author seems to be suggesting that some members of a team may fail to follow through when the build breaks down, choosing rather to concentrate on their own portion of the code.

Hope I'm not leading you too far afield.

Ivanhr · Answer

Avangi"Build breakage" would be the occurrence of a failure, or a breakdown, of the software as compiled in a particular build. It would not necessarily be a complete failure, but some aspect of it is not performing correctly.

I agree with Avangi. Building a software project requires both compiling and linking the project.

MrPernickety · Answer

AvangiThis is probably Pernickety's area, but my understanding is that a given build is similar to a given "version," only more refined.

Hi, Avangi

Project building is a bit outside my field of expertise but I think I can let you in on how it's done

. When you set out to compile a project (or better yet, a solution which embraces several projects. For instance the project I'm working on comprises as many as 22 projects), the programming environment (a humongous program that manages solutions, in my case it is Visual Studio) first tries to compile the solution and if no compiling errors have shown up in the process, it runs so called unit tests on the solution. If the tests haven't turned up any errors, the solution is considered successfully built.

I guess breakage refers to the errors that show up at compile time and and the errors that show up during unit test runs.

For example, I've run into a few situations where a developer checked some code into the solution that caused the whole solution to fail during building. Such occurences bring about extremely galling delays in coding, on account of you have to wait for that developer to ratify the code he mistakingly checked in.

Avangi · Answer

Your use of "checked in" is a new one on me. Is an outsider allowed to simply add on to an existing program and assume it will work?

I was picturing it as routines A, B, C, D, and E being successfully linked, and all maintaining correct function. Then F and G are added. F and G function correctly but now B and D are not working right. [:^)]

An unsuccessful build?

Ivanhr · Answer

AvangiYour use of "checked in" is a new one on me. Is an outsider allowed to simply add on to an existing program and assume it will work?

I was picturing it as routines A, B, C, D, and E being successfully linked, and all maintaining correct function. Then F and G are added. F and G function correctly but now B and D are not working right.

An unsuccessful build?

The build must have been successful otherwise you wouldn't be able to run the program.

An outsider can certainly add new functionality to an exisiting program. Usually this is done via plug ins or add ins. These are basically dlls (dynamic link libraries) which export routines accessed by the program. The program exposes an interface by which it can interact with the added modules.

If given the source code the programmer can add new routines and then (try to) rebuild the project.

If you add new routines you better not change any global variables that the old routines might be using. If your new routines F and G have changed some global variables used by B and D then it's no surprise they're not working properly anymore. There could be other reasons for B and D not functioning correctly, which are inherent to the build process itself.

MrPernickety · Answer

AvangiYour use of "checked in" is a new one on me.

OK, let me expatiate on it a bit more, I'm gonna go into details as best I can, so roll up your sleeves and brace yourself for some technical details.

(I hope I won't bore you to tears.)

We have a contraption called TFS in place (TFS stands for Team Foundation Server) . TFS is a humongous program (about as humongous as Visual Studio and it is an add-on to Visual Studio, in that you can opt for installing it and using it within the bounds of Visual Studio). Its primary purpose is to allow a slew of developers to work on a single solution, making changes to it that wouldn't clash too much (eliminating all possible clashes is impossible). The idea behind this is as follows: The solution is stored on a remote server and all deveoplers can access the solution on their PCs by way of this mysterious TFS. In more detail, they can download a copy of the solution from the server and work on the copy locally, from their PCs and make necessary changes in code. After they are satisfied with the changes, they need to upload them to the server, so the other developers can download these changes, if need be, and see them. This process of uploading changes is called "checking in". But before you can edit any file, you have to notify the TFS of your intentions. This process of notyfying is called "checking out". For example, you need to change file ***.cs, first you have to check ***.cs out. Then you change it. Then you check it back in. The point is that TFS is USUALLY customised in a way that allows for only one developer to have ***.cs checked out in his name at a time. If someone else wants to edit ***.cs, he would just have to wait for the developer that has it checked out at the moment to check it back in.

Here is where problems with build breakage start to creep in. For instance, developer A checked out file a.cs and developer B - file b.cs. A modified his file as he saw fit. Having ascertained that the solution built successfully after that and everything seemed to be in order with the solution, he placidly checked his file back in. In turn, B modified his file and made sure that the solution built after his changes, after which he checked his file back in too. But B had been unaware of the changes A had been making of course. Hence his changes may not have been congruous with the changes made by A and this potentialy may have created errors that could preclude the solution from building in the end. The consequences of such clashes are anything but pleasant. You have to be on the lookout for others and pay mind to what they do to the solution.

That said, such clashes occur quite rarely, but if they do, they can easily grind the whole deleloping process to a halt, until the problem with the solution is resolved.

With that in mind, at least once in a day the build manager builds the whole solution (from the server) and puts out the build for testers to test. Testers are people whose primary responsibility is to put software to the test

Needless to say, that if the solution is disfunctional at the server due to build breakage, testers can't go about their duties because there's nothing to test. This incurs additional losses in time, as the testers have to twiddle their thumbs in leu of testing a new version.

There, I said it!

A word about software development

Top answer

Get the Weekly English Kit 📬

Related Questions