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
- It is bullshit (and the other developers know this).
- It kills open discussion.
- 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?
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… Read more »
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.
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”.
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.
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
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.
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… Read more »
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… Read more »
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… Read more »
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
Vassilis
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.
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… Read more »
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… Read more »