Feed on
Posts
Comments

Coach The Build

You know, I always carefully vet the coaching advice that I give out. I do it by going out to gigs ignoring my own advice, then studying how everything turns to shit. Thankfully, I’m very handsome and can generally get by on my looks.

Not too long ago, I went out and demonstrated that TDD really doesn’t work if it takes ten minutes to go from ‘save’ to ‘pass/fail’.

Science marches on, yo.

An uncoached build

What Is The Build?

We don’t talk that much about “the build”. I gesture to the build, and we all kinda know what I mean. Doesn’t feel good enough.

The build is all the aspects of a development environment that are required to enable a given technique.

Notice that this is a very broad definition. Here’s a few examples to help get it right. Every one of these items would make true TDD almost impossible:

  • Compilation times greater than a minute;
  • No way to run directly on the developer’s box;
  • No way to separate “our code” from “their code”;
  • Source control that requires advanced degrees to use;
  • Source control that has every developer on a separate branch (I am not kidding.);
  • No way to test without bouncing the local web server.

This list could go on quite a ways further if I sat down to list every TDD showstopper I have ever encountered in the field.

The Moral: Expect To Coach The Build

3 Responses to “Coach The Build”

  1. John Stoneham says:

    Do I read in the above an indictment of Git?

    • GeePawHill says:

      What I was thinking of, though, was clearcase, accurev, and oh god yes, perforce. There are people whose *entire* *job* is just administering clearcase.

      What I want from an sccs is a) let’s say what an eclipse/cvs will offer with b) occasional, as in once quarter, freedom to do bizarre stuff one has to do thoughtfully and by hand.

      Applications or house rules that force one to permanently live in the “b)” world are an abomination, and should be promptly dismissed. We can find a good job for that guy who administers it, in some other capacity. Hell, he’s proven he’s smart enough.

  2. david thomas says:

    My fingers are screen burned with sticky tags and merge options. I still use subversion today for small projects (e.g. 10 people) but maintaining the build / TDD test heartbeat across 20-50-100-500+ people in teams across the globe… branches suck. and requires dedicated resources just to do CM.

    In the same way that you’d replace a shovel with a backhoe or carpool to work instead of riding your bike…. Taking an object-oriented approach of software configurations just makes sense. Inheritance on update!?!? . It’s brilliant! share changes implicitly across your peers/teams/globally, instead of manually. This entirely eliminates the mess of private branches and allows individuals to collaboratively dev/test in more realtime while still separating “ours” from “theirs.”

    I’ve started consulting the stream-based approach to CM instead of hard branches. You could argue that clearcase config specs allow you to emulate streams… but it requires manual management of adjusting rules – hence the admin requirement. Meh. They are still on the old branch model. I think accurev’s model is the cleanest so far. if I am doing TDD but working along side other peers or teams, my daily ‘update’ will automatically incorporate their file changes… not just my local ‘feature’ or ‘branch’. so my TDD is more realtime in a global scope but in local context. In a large[r] environment, I can’t imagine working in any other model. $ rm -rf /usr/local/[branch-based-scm-binary]

Leave a Reply

AWSOM Powered