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?
Hey,
Not to pick on the entire post but a comment on the interface definition discussion example you used; I've had that exact discussion and the reasoning was that the tests you write are actually your second implementation. That is, if you use the class as a dependency, you're better off creating an interface and then either mocking it or implementing an in-memory dummy implementation for test usage. Of course if the actual implementation already fits the bill or you're not interested in testing this doesn't apply.
Other than that, monkey see, monkey do. Coming up with new ideas can be incredibly hard.
That is a fascinating argument and one which I cannot invalidate. I know that it is possible to mock concrete classes with Mockito. However, it does feel a bit like blasphemy and like you said, sometimes a dummy implementation is a better choice than a mock object.
I agree that coming up with new ideas is extremely hard. That is why I think that it is foolish to put our hope in one man (or woman).