Each software development team is different from the other. What works in one team might not work in another.
Each team must agree to some set of values when working on a project.
A team must make a new participant agree to their set of values.
A new member of a team must agree with the team’s existing set of values.
I’m a TDD fan. But many others are not.
And I have never been in a team which practices TDD, but the apps I was and am involved in are working just fine… I hope 
! (Actually they were not very fine if we use Uncle Bob Martin’s standards as our measure, but I’m not going to incriminate myself or my teammates here 
)
So when it comes to TDD, I’m negotiable. I’m not a TDD fanatic — at least not yet 
. But let me experience TDD… I believe I’m never going back… I hope…
But there’s one thing I don’t want to be negotiable on anymore (when I will be involved in a software project from the very start). And that is the proper separation of the business rules from the other parts of a software system, and taking proper care of them.
The business rules are the most important part of a software system. They are very important to the business people we work for; they must also be very important to us — even more important than the frameworks and databases that we love. Uncle Bob Martin said that we must treat them as, what he calls, “family jewels”.
But… still… I long for the day when TDD (or anything similar to it) will become a common practice of software developers.
I long for the day when all software systems will look the same — when they will all look “testable”. That means that the software systems will be easy to work with! Yehey!
(I actually have a secret agenda for helping promote the proper separation of the business rules from the other parts of a software system — when I will become a part of a team that do not practice TDD, I will still do TDD with the business rules 
)
