Here at edc4it, we became more and more are convinced there is a staffing issue when using Test-Driven Development (TDD), test-first or test-whenever. Not so much TDD on itself, but more the impact it has on a development team.
One important attribute of TDD is that a developer follows a test-first development rhythm. A project team consist often of different level programmers. Often a large part of the team consists of mid-level developers. There is nothing wrong with that: they get the job done, on time and within budget. You can’t always staff a project only with development gurus. These skilled developers are very well capable of implementing the necessary business logic within the application. The problem however is at the test level. We believe that, in order to write (good) test, one needs to be more than a middle-class developer. Understanding the tricks, techniques, APIs and frameworks etc used, require more skills and experience than producing the core application code. Yet we ask all developers to first write their own test-code before diving into the application code.
We would like to hear how teams are dealing with this (and how developers experience that they suddenly require much more skills in their daily development work)