Home » Software Development » We Should Not Make (or Enforce) Decisions We Cannot Justify

About Petri Kainulainen

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.

We Should Not Make (or Enforce) Decisions We Cannot Justify

Software development is a strange industry. New technologies emerge in a fast pace and old technologies become obsolete. The ability to learn new technologies is considered as a sign of a great software developer. It is expected from all of us.

And yet, all of us don’t welcome these new technologies and ideas with open arms. Let’s consider the following imaginary discussion between a developer and the architect. Also, let’s imagine that we play the role of the architect.

A developer: “Can we leave out the service interface if we have only one implementation?”

The architect: “No. We might want to create another implementation in the future.”

A developer: “When was the last time we had to create a second implementation for a service interface?”

The architect: “Ummh. I cannot really remember but we still have to create the service interface. It is the best practice. It is how we do things around here.”

A developer: “But why? If we have only one implementation, creating an interface for it doesn’t make any sense. Besides, we can use the extract interface refactoring later if we need to create a second implementation.”

The architect: “Just create that damn interface.”

A developer: “…”

Discussions like this are (sadly) common in the software development field. Every day technical authorities make and enforce decisions they cannot justify.

Honesty Is Not a Virtue

We hide behind terms like “company policy” and “best practice”. There seem to be a general consensus amongst bad architects or other technical authorities that after an argument like this made, the discussion is over.

We should not fall into this trap. We should not misuse our technical authority in this way because

  1. It is bullshit (and the other developers know this).
  2. It kills open discussion.
  3. Those arguments are rarely the REAL reason why we rejected that request. They are just excuses.

Let’s face it. We want to stay in our comfort zone. We have spend a considerable amount of time to learn these technologies and practices which we use in our daily work. We don’t want that anything threatens our livelihood or makes our hard earned competence obsolete.

Instead, we get stuck in our old habits. Old habits are safe and they make us feel that we are in control of the situation.

Of course, no one wants to admit this because it is kind of ugly.

That is why we invented company policies and best practices. They are very convenient because they help us to enforce our opinions without the need to justify them. They are also a great way to demotivate the other developers.

We must remember that developers love solving problems and they know that every problem worth solving has more than one solution. It is their job to evaluate the pros and cons of each solution. It is their job to select the right solution.

If we take away the best part of software development, the only thing that is left is manual coding. Are we sure that we really want to do that?

Rank Should Not Be an Issue Here

The “winner” of our discussion was clear before the discussion was event started. The selection of the winner was not based on the arguments used in the discussion. It was based on rank.

The funny thing is that all of us agree that there is no silver bullet. If this is the case, why some of us still think that their way is the only correct way to solve a particular problem?

Many developers complain that architects are sitting in their ivory towers and have lost their touch with the reality. It is ironic that when these developers become architects, they have no problem moving into their new office, and into the ivory tower.

Are we sure that we want to follow this path?

In the end, we have to decide whether we want to enforce “company policies” or build a healthier work environment which is based on open discussion and empathizes continuous improvement.

If we end up making the making the right call, we should get rid of articial ranks and embrace open discussion. We should let the best opinion win.

What is your opinion?

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!


1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design


and many more ....


Receive Java & Developer job alerts in your Area from our partners over at ZipRecruiter



  1. Nice article Petri.

    I agree with you… i would not support pulling rank when it comes to making tech decisions.

    In the specific example…i would definitely not write the interfaces …. but on a related note… i have faced similar dilemma: We had used Business Delegates JEE Desing pattern … some these were just pass throughs….but some had to make calls to multiple individual services and hence this pattern made sense….

    what should we do for the pass through ?… keep them because that would make the design consistent ? or have two different arch patterns….some flows will go through a facade and some will not ?

    We finally made a decision, as team, and prioritized design consistency higher then the issue of having a support engineer having to deal with two approaches …

    Was that a good decision or not…. i do now know… but need to find that support engineer to really get the answer….

    There are so many such dilemmas that engineers face…. i guess there are no one right answer…but i agree that one need not pull the rank on others.. make a decision that everyone understand and why that choice was made.


    • Petri Kainulainen

      I want to thank you for your kind words. I really appreciate them.

      Your story was quite interesting. It reminds me of the tradeoffs which we have to make in our profession. I think that as long as we understand why we made a particular decision, it is perfectly fine to make mistakes. When we understand the reasons behind our decision and the tradeoffs which we had to make, we can learn from our every decision.

  2. In your example the architect is right, but cannot articulate his reasons maybe?

    The Real answer should be:
    “So that we can MOCK it in our Unittests”. Implying: “So that we are strongly decoupling this layer”.

    • Petri Kainulainen

      I think that opinions have no value without the arguments to back them up. Since the architect could not justify his decision, he was wrong. If he had tried to justify his point of view, he could have dealt with the situation in a proper manner.

  3. I Agree.

    Other than that, when i wrote that post i wasnt thinking that you could actually mock the concrete Service also. But it would be awkward in my opinion

    • Petri Kainulainen

      Mocking concrete classes has its limitations but it can be quite useful when you are working with a code which you cannot change for some reason. Nevertheless, I agree that it should be used only as a last resort.

  4. While I understand this may just be an example I think that both the developer and architect should really think about what an interface is. Different implementations is far from the limit of the benefits. It presents a simpler form to the developer without presenting details of state or public methods used as part of a different class. Many popular frameworks require its use for AOP ,remote proxying or unit testing.

    In the case of a dependency injection framework logging, transactions etc can be tested / introduced without code changes.

    So whats the down side. One extra file in the project. Theses no performance hit as if there is literally only one implementation HotSpot will optimize the virtual calls away.

    I agree developers should know what they are doing and why they are doing it. However I’m not sure I would want to work with a developer or architect that can’t figure this out. If for some reason I did, I hope that because they can’t figure out the very good reasons for something they wont break the good practices I or someone else set in place.

    • Petri Kainulainen

      I think that this example is quite interesting because like you said, it is considered as a best practice. Maybe that is why these practices are not often justified in the manner they should be. One reason for this could be that the architect (or senior developers) assume that everyone knows what are the benefits of these practices.

      However, often these practices are accepted as a fact. That is why I feel that best practices can be dangerous because if we don’t question them, we might miss a chance to make things better. After all, if Copernicus hadn’t questioned the status quo, we might still believe in the geocentric model.

  5. I understand it might just be an example but the interface vs concrete class is a poor one. Both the developer and the architect have failed to understand the issue.

    Firstly it keeps a clean view of what the class requires. A developer will not see public methods required for initialization or satisfying some other interface.
    Secondly in many dependency injection frameworks it allows the use of AOP for transactions,logging or remote proxying without having to change the code.
    Thirdly it allows you to use mocking frameworks (many which work with classes) or just write your own stubs (are you going to do your own bytecode weaving?)

    I’m sure other people can mention more good reasons. Now for the down side.
    Its 1 extra file in your project. Oh and there’s no performance hit because if as you say there is one implementation hotspot will optimize it away.

    So finally I understand the point of your article is not to argue about creating interfaces but an issue that you raise is a developer and architect who don’t understand why a senior developer started this practice and now the developer takes it upon themselves to change it. I think being a bit more humble and accepting if there is little cost these practices may be there for a good reason even if you and your architect can’t see it.

  6. Hello Petri,

    This is an excellent article which can be abstracted to general human behavior.

    A valid reasoning behind an action is vital in order for someone else to understand or to convince the person who you talk to. Ranking plays no role, it is our actions and our reasoning behind them that defines us.

    Thank you


    • Petri Kainulainen

      Hi Vassilis,

      I am happy to see that you noticed the psychological aspect of my blog post. If we look at software developers who have done something really remarkable, we notice that most of them have very good communication and human skills. That is why I am interested in human behavior and I think that studying it will make me a better software developer.

  7. I agree. I like the idea of enforcing only decisions you can justify, but above all I like the attitude behind. Meaning being transparent, reasonable, be driven by reasons and not by ranks… On the other hand, most of the times Best Practices are for reasons. I mean, if Martin Fowler, Kent Beck, Craig Larman, Rod Johnson… agree that X is a Best Practice, it is very dangerous that a team of average level developers discard it just because they don’t agree or understand why. So I would always agree with this post, but before discarding a well know Best Practice, make bigger efforts to make sure you really understand the reasons those master would argue. Nowadays I know how to justify the use of interfaces (just to follow the example above), but 8 years ago I just used them because it looked convincing the way it was explained: I don’t regret it. On the other hand I also admit that when you don’t understand completely a Best Practice and its value, usually it automatically becomes less useful. A good example of this could be a bad programmer creating a Unit Test just to increment the Test Coverage even if the test itself is really stupid and doesn’t add any value.

    • You made some interesting (and good) points in your comment. Best practices definitely exist for a reason. One thing that is common for all extremely successful people is that they are often very good at communicating their ideas. I think that this is one reason why they are so successful. If they would not bother explaining their ideas, the odds are that no one would care about those ideas.

      I have two reasons for feeling that giving a proper reason for each decision is important:

      First, it gives other developers the possibility to challenge our decision. If we want to find the best solution for the problem in hand, this is a great way to do it.

      Second, I think that spreading knowledge is an important responsibility of a technical authority. Also, this benefits both parties. The younger developers learn new things and the older developers have to look the problem from another perspective.

      I want to thank you from comment, it gave me something to think about.

Leave a Reply

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


Want to take your Java skills to the next level?

Grab our programming books for FREE!

Here are some of the eBooks you will get:

  • Spring Interview QnA
  • Multithreading & Concurrency QnA
  • JPA Minibook
  • JVM Troubleshooting Guide
  • Advanced Java
  • Java Interview QnA
  • Java Design Patterns