The Rules of Programming

Rule 12. Big Teams Need Strong Conventions

The most basic idea in this book is that programming is complicated, and that your productivity as an individual and as a team is gated on that complexity. The more complicated you make things—or let things become—the less successful you’ll be. The simpler you keep things, the more successful you’ll be—so keep things simple!

That advice holds true no matter what sort of project you’re working on, but it’s truer for some projects than others.

There are projects that are small enough and simple enough that unnecessary complexity won’t really matter. If you’re writing a hundred lines of code by yourself in an afternoon and you’re going to throw away the code when you’re done, then you can write that code just about any way you’d like and get away with it.

Once you’re on a team, even if it’s a two-person team, that’s less true. You might try to draw lines between “my code” and “your code,” with each of you deciding how code gets written on your side of the line…but this won’t work very well. Unless your two halves are extraordinarily cleanly separated and remain that way through the life of the project, you’ll be popping back and forth across the boundary routinely. Even defining the interface between the two halves gets problematic—for example, who decides how things in the interface are named, when half of the interface is on each side of the line?

There’s no good way to extend this my-side-your-side pattern to larger teams, but that doesn’t ...