Years ago, William Rowden and I owned a business. In that business we wanted to build amazing software for our clients, and we adopted several practices to help us do this.

One of the central practices we employed was test-driven development—a practice that essentially instructs you to write software like this:
1. Figure out what you want the code to do
2. Write a test that says, “Does this happen?”
3. Run the test and watch it fail (You haven’t written the code yet, so it had better fail.)
4. Write your code
5. Run the test
6. Watch the test pass

This is important to do because software development suffers from more product quality issues than brain surgeons in the 1500s.

But what happens to people when under the influence of a good idea?

They want to do it more. A lot more. Rowden and I wanted our coders to write good code that anyone in our company could later pick up and extend with very little hassle. We wanted to build quality in up front. Therefore, we went looking for “best practices.”

Best practices are like common sense: Everyone says they are the same and everyone does them differently.

 …