Why is software architecture so important anyway? It helps us to implement large systems. By structuring code into modules, we can ensure that developers only need to understand the module to be changed in detail to make changes. Only superficial knowledge is required of other modules, for example about the interface. This principle is called “information hiding”: details are hidden in the modules and can be changed with little impact on other modules. In this way, modules can ideally be understood and changed in isolation. If the architecture is particularly successful, developers can make changes to the software with little knowledge and therefore particularly easily.
By “good” developers we would like to introduce ourselves here as people who understand and can further develop complicated systems. Such people can also deal with architectural failures where changes are not that easy and may have hard-to-understand implications – sometimes in entirely different parts of the system. They may even find it intellectually challenging and enjoyable to engage with such problems. In addition, these circumstances ensure not only a secure job, but also prestige. After all, these people are often the only ones who can still change important systems and are therefore of great value to the business.
Anyone who writes illegible code is considered competent
Indications of such an understanding of “good” developers can also be found elsewhere: For example, anyone who uses the subtleties of a programming language such as Java in the code, which are queried in a certification, does not create code that is particularly easy to understand and change, but straight one that fully exploits the features and relies on special properties of the language. The code is particularly difficult to understand and therefore to change. Nevertheless, such certification is recognized as an indication of the developer’s ability. So anyone who can write or read particularly illegible code is considered particularly good.
Such developers may dislike “academic” architectural approaches and prefer a “pragmatic” approach. After all, they even benefit from the situation. It works up to a certain level of complexity. With “really good” developers, this leads to an alarmingly high level of complexity. You then understand systems that are a mystery to outsiders. But then the work of the software architects will probably not fall on fertile ground. After all, the system can be further developed – so why structure it better? In fact, the architect may eventually even leave the team to find another position where her efforts make more sense. And therefore “good” developers are the natural enemies of software architecture.
What is real competence?
The problem is understanding when women developers are considered “good” in the sense of competent. Of course, developers need to understand technologies. It’s certainly an advantage if you can handle complicated code, but you should avoid such situations and certainly not work towards them. Really good developers prefer to work on simple code. You just have an aversion to complicated code – and then developers and “clean” architecture have the same goal.
We can create an environment in projects in which “clean” architecture can assert itself. We shouldn’t congratulate developers for making a complicated change all by themselves. Instead, the focus should be on how to avoid such complicated changes in the future and how to empower more people to make such changes. To encourage the development of good software architecture, we should reward positive ways of working and correct negative ones. Instead of focusing on a developer’s individual ability to handle complicated code, we should focus on the quality of the code and the implementation of the architecture.
It is also important to have a broad interest in topics that are not related to the purely technical aspects of development. This helps to understand the domain, the requirements and the users and to implement the right features. To do this, however, you have to have an original interest in the domain and the subject matter – this is easier for people with a broad spectrum of interests.
tl;dr
Software architecture is an important means of containing the complexity of software. Developers who are also able to deal with complicated systems could reject such an understanding of the architecture.
()