Best practices are the backbone of software development (or so we are told). Every developer has his own opinions about software development processes, architecture, and programming.
These opinions are based on education, personal experiences, and the experiences of other software developers.
These opinions are also known as best practices, and every software company has them.
Are best practices a good thing? Not necessarily. I argue that best practices have a dark side which is often overlooked.
Beware of The Dark Side
Best practices itself are not dangerous. They become dangerous when they are misused or misunderstood. Sadly, this is quite common.
In my experience, the three most common ways to misuse best practices are:
Best Practices Are Treated as a Silver Bullet
When best practices are treated as a final solution, questioning them is not allowed. If we cannot question the reasons behind a specific best practice, we cannot understand why it is better than the other available solutions.
This means that we lose the opportunity to learn and improve the current situation.
This would be a valid strategy if we would live in a static world. Of course, this is not the case. We all know that new technologies are emerging in a rapid pace.
Are we sure that we want to be left behind?
Best Practices Are Used for Office Politics
In this situation, best practices are used to enforce the interests of a specific group. The two most common ways to do this are:
First, best practices are used to secure the position and authority of senior developers and architects. The whole organization has to use the technologies and programming languages which are familiar to senior developers and architects. All new technologies and programming languages are shut down as too young and immature.
Second, best practices are used as a marketing tool. Their purpose is to create an illusion that the organization is following good software development practices. Having a good looking facade is the only thing that matters because
- It makes the company look good in the eyes of customers.
- It makes the middle management look good in the eyes of their superiors.
However, the reality is that no one cares if this really is the case.
Well, that is not entirely true. The developers probably care but they are often "asked" to bend over and take one for the team.
The problem of office politics is that it tends to demotivate everyone who does not benefit from it. Does that sound like a worthy goal to us?
Best Practices Encourage Over Engineering
Sometimes best practices cause a situation where concepts like architecture, design patterns and reuse are valued above all else. The programs (or components) which are implemented by following these principles are often over engineered monsters. It is amazing how complicated software can be when it is designed by a team of architects.
This situation is caused by the inability to understand the difference of a a reusable component (framework, library, or service) and an application. This difference is clear:
- When we are creating a reusable component, we have to design it to be reused.
- When we are creating an application, we have to concentrate on the requirements of that application.
It makes no sense to over engineer a piece of code which might never be reused. And yet, this is what happens if we think that we should use the same design principles in every situation.
What Should We Do Then?
First of all, we should do our job. If best practices get in the way, we should not follow them. This might sound a bit radical, but we should understand that the whole idea of best practices is to find the best possible way to develop software. Thus, it makes no sense to follow a best practice which does not help us to reach that goal.
We must understand that there is no silver bullet. This means that there is no single method which can applied to all situations. Most of us understand this but for some reason, we forget this when we hear the words best practice.
Instead of treating best practices as a silver bullet, we should understand that a best practice is a method which works in a situation where specific preconditions are true. If we understand this, it is clear that
- We must be curious enough to constantly look for better solutions to our problems. The thing is that we are learning new things every day. A best practice which makes perfect sense today might feel stupid next week. We must remember that nothing lasts forever. Not even best practices.
- We must be brave enough to challenge the best practices when they don't make any sense. It is possible that we are wrong but if we don’t challenge the best practices, we will never know the truth. Can we really live with that?
- We should not follow a best practice which is not explained properly. Instead, we should demand for a better explanation. If none is given, we should ignore it. Only a fool follows a method which he does not understand.
In the end, best practices are just opinions. It is true that some opinions carry more weight than others but that doesn't mean that those opinions cannot be proven wrong. I think that it is our duty to overthrow as many best practices as we can.
It helps us to find better ways to do our job.
Excellent article! Very well explained indeed.
Thank you for your kind words. I really appreciate them.
Hey Petri, great post. Sometimes best practices stop people from thinking independently and creating solutions. Hope you keep up the great work.
Can you tell me how to Test the Spring data jpa and hibernate using TestNg
Unfortunately I have never used TestNg. I have only written a blog post that describes how you can write integration tests for Spring powered repositories with JUnit. That being said, I found a good (but a bit old) blog post that describes how you can use TestNg instead of JUnit.
I've been reading your blog for some time and I've learned a lot from it. Big thank you for this!
Now it's time when I'm thinking more about 'good practice' in designing of web app.
I have seen in your examples (like this: https://www.petrikainulainen.net/programming/spring-framework/unit-testing-of-spring-mvc-controllers-normal-controllers) that you return to controllers entites, which are detached (transaction is set at service layer). In examples you use simple entities without references to others. In real live entities have fields which are often lazy loaded like collections. In those cases you have to be very careful not to get LazyInitializationException in controler or even worse in JSP page.
What is your opinion about dealing with those type of problems?
The examples of that tutorial return entities mainly because I didn't want to make things too complicated. That tutorial is also a bit outdated, and I should update it in the future. In any case, nowadays I write services that return DTOs because this allows me to hide the data model of my application (and I don't have deal with problems caused by detached entities).