About Petri Kainulainen

Petri is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

The Dark Side of Best Practices

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

  1. It makes the company look good in the eyes of customers.
  2. 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.

Why?

It helps us to find better ways to do our job.

 

Reference: The Dark Side of Best Practices from our JCG partner Petri Kainulainen at the Petri Kainulainen blog.
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

4 Responses to "The Dark Side of Best Practices"

  1. I agree entirely! I’ve lost count of the number of times I’ve been told that I should follow a particular set of “best practices” or “standards”, only to discover that they differ wildly, and sometimes contradict, what was used on my previous project.

    I reserve the right to question anything and everything I see in a standards document. I have two questions in particular:

    (1) What is the purpose of this rule? What “good thing” is it supposed to promote? What “bad thing” is it supposed to prevent?
    (2) What “bad thing” happens if I choose to ignore this rule?

    If those questions cannot be answered to my satisfaction then I may ignore the rule, especially if it gets in the way of writing effective and efficient software.

  2. Bart says:

    Excellent highlight of these dark sides. It should always be upto the programmer to decide if ‘best practices’ apply to the situation at hand.

    I also recognize the office politics about them. Too bad, but often I find programmers don’t even know why they some ‘best practice’ is good (or in fact, not so much) but they apply it because their architect wants them to.

  3. Abu Raihan Md Rahat Hossain says:

    Great post, really liked it.

    Want to add something after following:

    As you said: “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. “

    I want to add: However, we have to be cautious, when we adopt new technologies because we know “Only a fool tests the depth of the water with both feet.”

    My favorite sentence from your post is “It is amazing how complicated software can be when it is designed by a team of architects.”

Leave a Reply


7 − two =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books