TDD course: what would make us happy?

Back in May, when I was just getting started on my current team, we had an instructor in to do most of a week training on Java, with the last couple of days devoted to TDD training.  As the Java training progressed, I wrote down some thoughts in the process of trying to define what success would look like for the TDD portion — what would make us happy?

Here are some of the things I was thinking, that week in May…


Big idea

I’d like to spend more time on best practices and figuring out how to really tie these  practices to day-to-day reality, and less on a description of the basic process.

Questions

  1. What differences are there when using TDD for modifying existing code versus writing new  code?
  2. Where does writing acceptance tests/integration tests fit in? Is this outside the red,  green, refactor cycle?  Invite the instructor to take a look at our architecture and give him an overview of  the kind of testing we’ve done so far… hear his thoughts on holes or weaknesses, inefficiencies,  in our testing strategy?
  3. How to maintain the discipline to do TDD in the face of deadlines/schedule pressure – Is pair programming a good way of dealing with this?  How do you answer for the apparent  inefficiency of “two people working on one thing”?
  4. How does the “refactor” phase interact with the concept of code ownership?  Should anybody be  able to commit any code, because this is needed to support refactoring?  Or are some restrictions  wise?  What effects has the instructor seen in shops that have code ownership controls versus  shops that don’t?  (My feeling is that the concept of code ownership can tend to work mightily  against a clean, well-factored system and that we should rely on the tests to show if a  refactoring has broken something… I’d like to know if there are other aspects of the issue that  I’m not seeing though)
  5. How do you mesh up-front architectural analysis with TDD well? James Coplien is vocal about the importance of this:

    I’ve seen a lot of Agile projects crash and burn after about their third external iteration for  lack of good architectural foundations. It doesn’t take much architecture to shape the whole —  just enough to keep Conway’s Law happy and to lay a foundation for the interface — but it takes  much more than Ron Jeffrie’s fabled “ten minutes of design.” Maybe a sprint’s worth is enough to  get started.

  6. Martin Fowler sees value in some architectural analysis too:

    “So my advice is to begin by assessing what the likely architecture is. If you see a large amount  of data with multiple users, go ahead and use a database from day 1. If you see complex business  logic, put in a domain model. However in deference to the gods of YAGNI, when in doubt err on the  side of simplicity. Also be ready to simplify your architecture as soon as you see that part of  the architecture isn’t adding anything.”

Could be helpful

  • An instructor-demoed example showing a large refactoring performed TDD-style (in Agile Java the big refactorings were where I had more trouble seeing how to use TDD and I started making a bunch of changes while I had a red bar, not knowing how long it would take to get back to a stable state or if I was going down a dead end)
  • Another such exercise that’s hands-on, where we practice doing a large refactoring (perhaps in  groups of twos)

Other Undefined Expectations

  • How much hands-on TDD experience do we wish for?  Or, is actually doing it during class not what we want?  (for some in the class, they’ve never done it and it could be a really powerful experience to actually do it… but then others of us have….)
Advertisements

, ,

  1. #1 by Matt on December 1, 2008 - 2:23 pm

    At first, paired programming looks inefficient but after several months of doing it, it pays off. Anyone on my team can pick up any project with little or no startup time. Everyone knows something about everything else. If some is out for the day, it’s not a big deal. Also any one in my team could be ‘hit by a bus’ and our team would not lose the ability to function.

    Along with protecting our projects long term success, it also helps Unit Testing. We can both think of scenarios to test and help drive out the design. This also helps to prevent over engineering the solution.

    So, I’ve become a big fan of paired-programming!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s