Right, because every service and application can easily be broken down into a set of tiny features that don’t interact and are all individually simple to test.
I often wonder what world some developers live in, to be unable to imagine a large module that’s impractical to partition and even more impractical to unit-test. It’s just not that easy… some things aren’t functional at all until they’re mostly done.
Even though this seems like common sense, I unfortunately run into developers all the time that don’t check in at least once before going home at the end of the day. So although many of us take this stuff for granted, and may even want to give Jeff a hard time about this blog post, there are many people reading this that probably think it is okay to go days without checking their code in.
Whatever value lies in this approach does not lie in particular tooling. Git certainly does not solve the problem; as long as the changes aren’t merged, you can still get conflicts or worse yet, difficult to track down semantic errors. If you can use this way of working (and sometimes it’s just not possible), then you have to actually share the changes with the other people working on the same codebase - nothing less actually achieves much. It’s not so much your committing, as it is their checking out of your changes (or a testers checking out of your changes) that provides the safety net.
Jeff,
Thanks for the mention. Looks like you really stirred up a hornets nest! You may be interested in reading some of my latest thinking on integration patterns in a post on Multi-Stage Continuous Integration: http://damonpoole.blogspot.com/2007/12/multi-stage-continuous-integration.html .
Cheers!
Damon
Cant agree more, that’s my rule of thumb too, besides if you don’t do that you almost automatically forget to check-in something