We have been building a new team at work which has me pretty excited. On the surface, the main benefit is that we get more people than, well, just me working on things for an exciting and growing line of business. But it goes way deeper than just that.

I have been using Cruise Control for a couple of years and this new team made me realize I was using it wrong. I had always thought it best to make a conscious decision when the build was ready for testing. Cruise Control could run all my unit tests and maybe a smoke test, but only a human could decide when a build was ready to pass on to another human to test.

One of the members of our team was formerly fixed in the role of tester in our department (now he is just a member of our team and I think he can do whatever necessary to make our team successful...a generalizing specialist) A couple of days ago, I finally got around to adding him to the e-mail publisher list for our builds. The process I was imagining was, "We should all know when the build is good or broken, but when I want to 'bless' a build for testing, I will just forward the Cruise Control e-mail notification with a little note or something. Without this blessing, the build is not ready for another human to spend time with." Unfortunately (or maybe, fortunately) I never got around to voicing this imaginary process.

Later, I started noticing that Jeff (the ex-"QA guy", current team member) would just run with the build notification and not wait for me to "bless" the build (it happened again just now.) I opened up a new e-mail and got ready to explain my imagined process when I realized that this was better. He _should_ be able to just grab a good build. Why would we check in a bad build?

One of the many excuses I use for checking in bad builds is that it's better to have the source code nice and safe in the source code repository than to have it sitting on one of my hard drives. Also, nice tight little single purpose commits make it easy to cherry pick things in case you need to merge them somewhere else later. Finally, nice little commits also tell a story better than a massive commit with a novella commit message.

So I could work out how to reconcile these two things - until just now. It sounds so simple it's stupid, but from now on I will concentrate on doing smaller _complete_ checkins. I will checkin as if I had 5 minutes left to live, and this checkin will be my sole legacy to man kind. I will imagine people looking at just the commits I have made and thinking "What the hell did he do that for?" whenever I feel the urge to check in something that passes unit tests but isn't deployable. If I absolutely have to leave without being done, I will use my version control systems fabulous branching support to "shelve" the changes I have made for later - but this will be reserved for "honey, I think I'm going into labor now"-type situations, since merging is still a little painful.

After all, these tools are all about reducing friction. If someone has to wait for an e-mail or some ceremony before they can do their work, then we're not reducing friction anymore.