That doesn’t mean that you shouldn’t use it, it just means that you must be aware of the danger. Chainsaws are dangerous too, but there are times you do need one. You don’t handle it without the proper security measures. You may not even want to consider getting near a chainsaw, but instead resort to calling a professional when you need one.

But when it comes to version control tools we programmers are the professionals. There is no one else to call.

We shouldn’t be afraid to use the right tools for the job. This is analogous to the fear that people feel about dynamic languages. People think they are just too powerful and can be dangerous in the wrong hands. But it turns out that this isn’t really a valid point: almost anything can be dangerous in the wrong hands. The point is that you shouldn’t have idiots working with you. If you don’t trust your team to use a powerful tool because it would be too dangerous for them, you shouldn’t design a safer, more limited tool. You should get rid of the team itself. If your team is already able to shoot themselves in the foot with a handgun, you shouldn’t buy them a shotgun. You should find yourself another team.

Idiots always find a way to be idiots, even if you design all the safeguards that you can think of into their tools. This is just what they are. Our tools should be designed to make the awesomeness of awesome developers shine, not to hide the suckyness of the mediocre ones.

Testing is also designing. When you write the tests before the production code in good TDD style, what you essentially do is to design how the code will look from the outside. Sometimes it may be hard to resist the temptation to design everything before writing a single line of code, specially for those used to waterfall thinking. For those who can’t help doing it, here is some news from yesterday’s paper: it doesn’t work. Even though everybody minimally informed has already heard it, this message never gets said enough.

It doesn’t work because designing is infinitely better and easier when we can have fast feedback. Software development can easily be a high feedback activity. Architects need to wait for the construction team to finish the piece and film writers sometimes need to wait years for the shooting to finish, but programmers can just compile their programs. Giving up this feedback on purpose is not the smartest thing to do. Writing all tests for a piece of code before starting the code itself is no different than drawing rectangles and arrows describing it in full detail before trying to make the whole think work. The risk of over-engineering is the same because the code isn’t there to scream in agony.

The key to avoid BTUF is writing the tests that you can come up with before writing the code to make them green, but making sure not to think too much. You can wait to start writing the code after all tests are in place, but you don’t need and neither want to.

TDD has shown us that design isn’t made only of diagrams. In fact, we are designing all the time we are developing software. TDD is only one of many design techniques: one that uses tests. It may be a better tool than arrows and rectangles in some situations, but is still just an approach for design. BTUF is, therefore, just an special case of BDUF where tests are used to determine the design completely before writing a single line of code.