The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Test before check in on "latest and greatest" branch

What's your take on checking in code on a "latest and greatest" development branch that immediately wacks down users.  What do you think of the notion that check ins which break the environment are okay as long as this occurs in development and eventually get fixed.  This is the "we know we're breaking the app" mentality.
Carpe Diem Send private email
Friday, January 07, 2005
 
 
There is no take. Checkins that break the build are bad. How could it be otherwise?
Ian Boys Send private email
Friday, January 07, 2005
 
 
What Ian says with the possible exception of a single-person development teaam.  If you are dealing with more than one person breaking the build for every one else is a Bad Thing.
0xCC Send private email
Friday, January 07, 2005
 
 
It depends on the size of the system. If it's a large system it may not be possible to recompile everything and run all the tests. In this case certain types of errors are to be expected. But if this isn't your situation, then one should never break the build unless it's just a mistake. I've been in the situation where i swore i ran the tests and everything worked fine, yet it didn't in the official build. Sometimes your local and official build environments are slightly different, so there always might be some problems.
son of parnas
Friday, January 07, 2005
 
 
Excuse my ignorance: does "breaking the build" mean things don't recompile, things dont test okay, or both?

Our team has a 1.1 version of its software in pilot, a 1.2 version going into pilot in 2 weeks, and a 2.0 version that is scheduled to be released into pilot in two months. 

It's the 2.0 build that I am concerned about.  Management and team think testing errors in the 2.0 build are okay.  This is what I object to: using a build (2.0 here) for a "check in first, test later" action plan.

Thank you for your comments.
Carpe Diem Send private email
Saturday, January 08, 2005
 
 
>  "breaking the build"

Means any unplanned error. That could be compile problem or test problem. Sometimes when integrating features you may plan to have the head break for a while, that would be ok, though you might want to consider an integration branch. This is especially true if the full testing process is measured in weeks rather than hours.
son of parnas
Saturday, January 08, 2005
 
 
I believe in the days of Netscape and development happening that anyone who broke the build got a toilet parked next to them in their cube until they fixed it.

Unfortunately, this didn't seem to fix the problem because people kept on breaking the build.  Quite what other incentive developers need to merge and test before checking in than the collective ire of their peers I can't imagine.
Simon Lucy Send private email
Saturday, January 08, 2005
 
 
If you check something in that prevents me from compiling and testing my new code I won't be happy.  At that point you've stopped other people.  If you check something in that breaks some tests specific to your code which doesn't have an impact outside of your code I won't care as much.
Lou Send private email
Saturday, January 08, 2005
 
 
> anyone who broke the build got a toilet parked next to
> them in their cube until they fixed it.
> Unfortunately, this didn't seem to fix the problem
> because people kept on breaking the build.

As long as the developers are just given cubes to work in, what else can one expect? :)
Morten Hanssen Send private email
Sunday, January 09, 2005
 
 
There are a few reasons why 'breaking the build' is bad. On a multi-person development team anything that prevents the other developers from using the most recent build is going to negatively impact their productivity - almost certainly more than the negative impact of getting the breaker to fix the break. Developers will end up either not working, or working on out-of-date code, which means fixing bugs that aren't really there, making changes that clash with other changes, or spending more time resolving edit conflicts. This really should be the definition of 'breaking the build' - anything that prevents the app being used by other developers. Obviously a failure to compile falls into that category, but so does a runtime bug that disables the app.

The other more subtle one is that allowing a merge that breaks the build is creating a low quality environment. Most developers (myself included) would rather start work on the next feature than fix bugs, given the choice. It's important to send the message that bugs should be fixed quickly - see The Joel Test for more details.
David Clayworth
Thursday, January 13, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz