It has been already some time since I started to oppose to idea of the Best Practice. Somehow it felt like an excuse to avoid thinking and using out-of-box solution. But I could not express my concerns well enough for the Best Practice Seekers and Followers to even start doubting it.

Now, I can use very good article Death to Best Practices written by Ted Neward. I encourage everybody to read it as well as an article linked there, but I offer my favourite part:

The point is, best practices just don’t exist. They are an attempt to take a solution to a problem out of the context and apply them across the entire spectrum, and that essentially invalidates the entire thing. A solution is only useful when considered in context.

Don’t believe me? Consider this challenge: when is it not a best practice to breathe? When you’re under water, of course.

(Unless you’re a fish. Or a frog. Or maybe a prince turned into a frog.)

Point is… context matters, folks.

I am looking forward for comments saying you actually can breathe under water, you just need to... But that would be only cognitive dissonance at work.

There is a value in the best practices, I have never doubted it, but I always suggested to use name good practices to show they are not universal truth. IMHO their value is in learning how experts solve particular problem in particular context, allowing to think whether it is a good match in our context, discussing differences in contexts and to think whether we could change our assumptions about problem we are trying to solve.

I have touched this topic before in Giving gifts versus conceiving rules and also in Is Javadoc useful?

Nearly 2 years ago I decided to organized unit testing workgroup with my colleagues. I found existing unit tests for product I was working at were not good enough to pay themselves off (being cheap to develop, reliable, easy to maintain and helping to grow production code instead of prohibiting it). I had prepared a presentation showing ideas, good and bad examples (there were less bad examples, because I was advised not to alienate my colleagues at the beginning).

Presentation went well (I thought), colleagues agreed to continue with these sessions weekly. They asked me to concentrate on writing The Best Practices. I objected, I didn't like the idea much, because IMHO it was wrong approach. You cannot create universal best practices, because you always need to consider context you want to apply them at. But I agreed to write Good Practices. In following 3-4 sessions we covered all ideas like expressive tests, data builders, testing scenarios instead of methods, ... Colleagues agreed they indeed are good ideas and that was it. Whole idea died slowly. I have linked wiki pages occasionally in e-mails, but I suspect nobody remembers it now.

My original thoughts were the colleagues were not ready and I marketed my ideas insufficiently. I am sure these reasons played certain role, but now I've realized there was big mismatch in our expectations of this workgroup. I wanted to give them a gift, but all they wanted were rules to follow. In way, they really were not ready, it is much easier to follow set of given rules and in case of failure the blame belongs to somebody else - "Hey, I've just followed the rules". I did not understand it then, because I was quite new to a company.

I've decided to continue with my gift giving (even I did not have this name for it then) in covert mode. Helping by making things better nobody asked me to do, I considered possibilities of enhancements when I reached some threshold of pain.

Sometimes I tried to provide a hint how to improve a piece of code, but that can be a bit risky in covert mode, because it allows for misinterpretations if not explained well. And due to my previous experience of refusals I tried to avoid getting into explicit mentoring mode. It usually depended on my previous experience with person I tried to help.

Situation is getting better slowly. Couple of people started to practice TDD, but others refuse vigorously even to try it. I am finding readable focused unit tests more often, but they are still rare compared to 50 lines long monsters you cannot understand even after reading its javadoc. There are people around who understand the power of finding better ways to do things, but many want to live in safety of rules made up 10 years ago (e.g. using StringBuilder for every concatenation, despite fact JVM optimizes '+' very well now and it is much easier to read) or to create a mess if there is no rule against it (e.g. copy&pasting piece of code 17 times and modify each copy slightly instead of making effort to find a correct abstraction - I should probably blog about this at some time). I still overhear from time to time "I would like to have the best practices for X", but it is less often than it was before.

What is difference between gifts and rules?

When I compare those 2 approaches, I like much more possibility to give a gift than to invent a new rule. The point is that with a new rule you are saying you don't believe people are able to do correct thing. Their genius certainly cannot shine if it is restricted with rules. Those asking for rules also express they don't believe themselves they are able to deliver.

On the other hand, by spending time with colleagues to show them how they can improve shows them I respect them and I believe it is not wasted time. And in the end it makes difference with product and our working environment.