What is “the right way”?
How do you know if you’re on the right path? There are just too many opinions out there on what “right” is.
You could spend a lifetime searching for “the right way” – and really, I believe you will. Because when it comes down to it, there are no “best practices” and there is no “right way” to build software – not in any absolute terms, at least. It always depends on the context of what you’re building and the constraints that you have to fit the software within.
If we assume that “best practices” are contextual – they are only “best” for the given situation, requirements and constraints – and that the “right way” to build software depends on the software we are building, then we have to change the question. Instead of looking for “one way to build them all” (“and in the darkness bind them”), we need to answer a slightly different question:
How do I know which way is the right way, given my circumstances, requirements and constraints?
The only viable answer that I’ve found for this is: experience. You need to pull in your own experience and the experience of others who have solved similar problems in the past. This can feel rather daunting or impossible for those without the experience needed. There’s a saying that one of my friends and former co-workers was fond of (which has been attributed to multiple original authors):
Good judgement comes from experience. Experience comes from bad judgement.
I’ve been there a thousand times – very recently, in fact. A few weeks ago, I found myself in a situation where I needed to use RabbitMQ in a largely, highly distributed system for a very large medical organization. I have a tiny bit of experience with RabbitMQ, so I thought that it would be a good solution. But I had zero confidence in my ability to “do it right”. So I told my client this. I told him that I believe a message-oriented, distributed architecture is going to be the best solution and explained why. I then mentioned that RabbitMQ would be a good choice and explained both my reasoning, and my concern about not having all of the experience I needed. They agreed with the reasoning and let me move forward with it anyways.
Since that initial discussion, I’ve made a lot of mistakes and wrote some horrible code. I read more about RabbitMQ, had some discussions with RabbitMQ experts via twitter, and found a better way to do things. I improved the code and the architecture. Things started working well. But I know I’m not done. I know I need to do more, learn more, gain more experience with RabbitMQ and improve my ability to use it correctly.
The critical point, here, is that I was both willing to step outside of my current comfort zone and willing to admit that I was not experienced enough to make good choices. I believe I can make better choice with RabbitMQ now, than I could a few weeks ago. But I also know that I am still not an expert and I have a lot left to learn. I’m ok with making making mistakes. Making a mistake doesn’t scare me. Not being willing to learn from mistakes scares me. Not being able to correct mistakes scares me. So I do my best to code in a manner that that allows me to make mistakes. I take an iterative and incremental approach to solving problems. I build a lot of throw-away projects to prove and disprove ideas. I try not to let 3rd party frameworks pollute my code everywhere, so that I can change out the framework when needed (this isn’t always possible, though).
Do your best with the information you have. Make corrections when better information comes in. Learn from the mistakes that you are making. Draw from the experience of others and assimilate their experience (even if you don’t understand it, yet). Step outside of your comfort zone and learn new and different things. Make mistakes, get help, clean up the mess, learn the lessons, repeat. Your judgement of what is right for any given situation will improve.