Writing code as part of a team is very different from writing it alone. Joel Spolsky’s list of things to look for in a software team highlights several differences. An important thing to remember when writing code as part of a team is DON’T BREAK THE BUILD. I’ll explain what I mean by that phrase, and why it’s important.
Most good teams writing code for pay use source control. Source control is important because it prevents changes from being lost, and it prevents coworkers from stepping from each other’s toes. It also means that there is always an official version of the code. (I will refer to the version of the code that checked into source control as “the codebase” for short.) It is common practice to do a daily build of the codebase (item 3 on Joel’s list). It’s really important that the codebase always builds and passes a set of baseline tests. Checking in code that prevents the codebase from building, or causing these baseline tests to fail is called “breaking the build”.
Don’t break the build. This commandment seems completely obvious, but it can be very easy to break accidentally. For example, a “harmless” one-line change may be checked in without doing a full rebuild (oops – forgot a semicolon), or without syncing to the latest version of the codebase (oops – a function name changed). On occasion it’s very tempting to break on purpose, for example when performing a series of complicated refactorings. (“It’s only temporary.”) It’s easy to rationalize and tell yourself that it’s no big deal. The problem is that it’s impossible to keep track of what everyone else on the team is doing, so a “harmless” build break may in fact totally screw over one of your colleagues. This is bad not only because it is impolite, but because there is a loss of productivity, and more importantly a loss of trust in the codebase. If you can’t trust that you can sync to the latest version of the codebase and build successfully, then you will inevitably start to get overly careful about the types of changes you make. The general attitude of the programmers and testers is fear of change. The team starts to treat the codebase as if it were a sleeping dragon.
A relatively simple way to combat build breaks is to have a dedicated “build loop” machine that does a full build and runs validation tests whenever a change is submitted to source control. If something fails, the machine sends out an email (or sounds an alarm, or sends an electrical charge) that notifies the team. It’s usually not that hard to set up, and it really pays off.
What should you do when a build break happens? The most important thing is that check-ins should stop until the problem is fixed. Again, it can be tempting to break this rule because you might think that your changes are unrelated to the problem. First of all, don’t be so sure! Second, be a team player. Help the team get back on its feet, even if it’s not your fault. If you encounter a build break, make sure it’s not your fault. Make sure your machine setup is standard (have you installed any new software? did you accidentally uninstall something your codebase depends on?) Make sure you don’t have any local changes that are causing other problems. If you’re convinced the problem is not local to your machine, make sure the team knows there is a problem, and start trying to fix the problem – even if it is not “your code”. Try to fix the problem yourself because 1) it’s the golden rule, and 2) you will probably learn something in the process, 3) it is probably the most productive thing you could possibly be doing. Breaking the build affects everyone, so ideally everyone drops what they are doing to fix the problem. If that is prohibitively expensive for your team, that’s a sign that you may want to get more sophisticated. Consider a “gated check in” mechanism where a series of tests are run on the build loop machine before the changes are submitted. This way it should be nearly impossible to break the build. Setting up a gated check-in mechanism takes more work, but there can be huge dividends. When programmers on the team know that they can take full ownership over the code base and get s*** done without fear of bringing down the house, good things happen.
My last piece of advice is the rule: “when in doubt, back it out”. If you can’t figure out what’s going wrong, undo the change. This takes the pressure off because the whole team is no longer blocked.
Programmers who are used to coding alone find this sort of talk off-putting. It sounds like unnecessary process, and certainly in the wrong hands these suggestions become burdensome. Don’t apply these suggestions blindly – use the ones that will result in a happy and productive team.