emphasizing refactoring as a task to be completed after arriving at a working implementation has so often become a point of contention for teams using TDD that it warrants valid criticism of the methodology. Typically, if a team is under pressure
Rules similar to the ones published by Michael Feathers in 2005 are common
Practitioners of Detroit-school TDD often favor “bottom-up” development, in which smaller units are developed first (in anticipation of their being needed by the larger system)
This tendency emerges because “outside-in” development would result in uncomfortably large units of work.
A significant drawback of bottom-up development is the opportunity for waste, dead code, and rework to result:
it’s fairly common that the subordinate components the developer predicts they will need won’t actually be needed when it comes time to plug them into the public-facing unit