We all follow best practices: we all look how successful companies do their business, how they structure their websites, how they organize their documentation. In case of software development, we peek which processes they use, how many spaces they use, which styleguide, which languages, frameworks and so on. It all makes perfect sense – we want to replicate success, we want to use technology which is popular and we can hire new people for, and we want to indicate that we also “belong to this group”.

Before implementing anything, we consult with existing solutions, to make something similar, yet distinctive – and it is just human nature: we bring what we already observed in our career, and what worked for us. There are also tons of evangelists, which promote their technology/process/approach of choice, giving endless introductory talks and blogposts, but without answering complicated questions.

Now, best practices and common knowledge are definitely good things, and it would be pretty crazy to say that you need to rethink everything; however, I don’t think we need to treat them as something written in the stone. A lot of this practices, though, try to monopolize “the single true way” (see ScrumBut, for example), and in general people are discouraged to try tweaking existing practices – usually experimenting means that you just look for an another approach, and try it out.

There is a great talk “You and Your Research” by Richard Hamming, which points couple of important things:

• in order to go for big things, you need to have courage. Ironically, going against best practices is considered something courageous in software development field, but you definitely need some.

Once you get your courage up and believe that you can do important problems, then you can. If you think you can’t, almost surely you are not going to.

• you should not read about solutions too much – try to understand the problem first, and then think about it by yourself:

If you want to think new thoughts that are different, then do what a lot of creative people do — get the problem reasonably clear and then refuse to look at any answers until you’ve thought the problem through carefully how you would do it, how you could slightly change the problem to be the correct one.

I also don’t want to say that just not using existing practices is a good idea – moreover, it is pretty silly to discard all acquired knowledge in our field. So, pretty often companies which don’t use any of those are not courageous or something, they are just ignorant. But if you see that something does not fit very well for your specific use-case (be it code, process or something else), think about giving a try to your own unique solution, without consulting existing solutions – at the end of the day, your situation is unique and their solutions are just theirs.