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?
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.