Recently I had a short but intense discussion in Twitter with Ari Tanninen about best practices. Best practices have been haunting me for a while so I came to the conclusion that I need to write a blog post about them.

First things first., I have one very profound problem with a thing knows as Best Practices. It is a bad term. It implies finality. Period. No room for improvement. This is it. No further. All trespassers beyond this point will be shot. Do not think.

Pure madness.

But, if you inject some context into best practices, you may get something useful. Let’s open that up a bit shall we.

Imagine you have a team of rookies. They have just graduated, know something about some programming languages and theory. How do you get them up and running? You tell and show them a good set of good practices that have been proven to be good. You give them a starting points. something along the lines of: Write the tests first. Automate your tests. Do not optimize prematurely. Ask questions. Ask more questions. And so forth. If they follow he advice you gave them they should not fail miserably. Let them learn from the experience of others.

But what if you have a bunch of craftsmen with several years of experience and that have been working together for the last 5+ years? Giving them something titled as Best Practices is effectively telling them to stop thinking. Imposing best practices will lead to trouble as these men or women will not follow your instructions. They will use whatever fits them best. Which will lead to a very interesting situation. Do they need to do what you or your company tells them? Avoid this scenario, at all costs. Pretty please?

Sometimes there might be someone in your company who tries to optimize your work without knowing the context or those nitty-gritty details. This may be even more disastrous than imposing practices from close proximity.

The road to hell is paved with good intentions.

Ignore these people (and if you have the guts, try to convince them that they are making the whole department/company worse, with 100% certainty).

There are no globally applicable best practices.

Everything depends on the context. We live and work within Complex Systems. Attempts to simplify such complexity into a container called best practices is not only impossible, but also futile and stupid. Things change, work evolves and best practices given from outside become stale very fast.

Best practices can be useful and give you a starting point when applied properly and within the correct context! Following a set of best practices may allow you to avoid some pitfalls that people before you have encountered, fell into and climbed up from. Best practices attached to a ShuHaRi-mindset allows you to learn from the masters.

Absolute beginners, novices, can benefit enormously by following the advice of experienced masters. But once you start learning and developing a skill of your own, you need to rely less and less on those practices. They become obsolete.  You can sidestep best practices and use those practices that fit your environment the best. When you know enough about your surroundings you can develop and improve the practices you use whenever and however you want. Best Practices are not a silver bullet. They will not save you nor improve your performance but they can help you to begin your journey towards craftsmanship.

What should you use then, if not best practices? I want to strongly suggest that you drop Best Practices for good and start using Good Practices instead. As a word, good has a positive echo, you can improve things that are good and you can even oppose a good practice if you can prove that there are better ways to do things. We all like things that are good and very often want to be better than good. Good practices give us the leeway to make things better.

There is always room for improvement.

Post filed under Software Craftsmanship and tagged , , .

Leave a Reply

Your email address will not be published. Required fields are marked *