Now that Devoxx Belgium 2019 has concluded and left everyone with a warm glow, it’s time to reflect on the best talks of this year’s edition. For me personally, Venkat Subramaniam‘s keynote talk on the qualities of a highly effective architect definitely tops the list.
For those who aspire to become a software architect or are determined to become a better architect than they already are, he delved into a number of points which in his view can make all the difference. And of course, he did this with his usual combination of wit, humor

Let’s dive right in …
Be a mentor not a tormentor
To paraphrase Peter Parker’s Uncle Ben, with great experience
Allow developers to figure it out
As a counterpoint to the previous one, when you yourself have plenty of experience while someone else is struggling with their task, it’s tempting to proverbially take over the steering wheel and hand them the solution to their problem. While this might speed things up in the short run, you’ll be preventing that other person from learning, which will cost you and your team time in the long run.
Guide, don’t dictate
When you are handing out a task, don’t micromanage how the task should be solved. Otherwise, you may be depriving your team (and your architecture) of alternative approaches that could be better than the traditional solution that you, as the architect, would suggest.
Criticize ideas, not people
When brainstorming, someone may come up with an idea that is less than ideal, that won’t work, or that very obviously (to you at least) makes no sense. You could then tell that person that their idea is stupid. Or you could say we can’t do that because it wouldn’t work due to reasons A, B and C. In the first case, you put the blame at that person’s feet (ensuring that they won’t speak up again), while in the second you acknowledge the idea, approach it as a team, and increase your team’s average expertise. To put it differently, it should be safe
Moreover, it’s very rare that there is just one ideal solution to a given
Practice collective ownership
It’s not uncommon for different people in your team to focus on particular parts of the code, while mostly disregarding other parts. This may seem more efficient because you’re building on individual expertise, but it leaves your project vulnerable to being crippled when a single person is e.g. on sick leave (the well-known bus factor). Furthermore, having a variety of viewpoints assessing all aspects of your code base will typically lead to higher quality code.
Prototypes beat any argument
Your team could lose a lot of time by following a technical direction that doesn’t work out. One approach to preventing this is by having many meetings before deciding on a direction. But then, your team could lose quite some time by having a lot of meetings, and

Gain domain expertise
It’s good to keep in mind that architectural solutions are not meant to be demonstrations of technical expertise, but instead should serve as solutions for your domain. Doing that without deep domain knowledge, or at least direct access to people with that knowledge, is near impossible. So first and foremost, focus on your domain rather than the technologies.
Learn to unlearn
Even if you have acquired a lot of technological expertise, that expertise will inherently have a limited shelf life. This means that the current best practice for any specific thing might (or even, very likely will) in the future no longer be the best approach. So prepare to change your mind.
Diversify your knowledge portfolio
In the same way that your architecture can benefit from new developments, so too can you improve it by being aware of a broad range of existing technologies and approaches. This does not mean that you should be an expert in all of these; being aware of their existence and their concepts will go a long way.
Lead by example
It’s useful, and even productive, to rely on varying strengths and skills in your team. It’s counterproductive however to delegate a task to someone who doesn’t know how to perform a given
Write code
With software architecture, as with most other things, the devil is in the details. And in software
Evolve the architecture
The architecture for an application depends greatly on the information that is available. However, during the first stages of a project (or before it has even started), information is far from complete, typically lacks in details, and necessarily cannot include insights that are gained during the course of the project. As such, it makes little sense to create a full-fledged and final architectural design upfront. Instead, it pays to start with a general architecture based on the scant information that’s already available, and let the architecture evolve along the way, when more information and insight is gained.

Final remarks
Many of these points may seem obvious when presented on their own. That

Alain Van Hout
Java Software Crafter
Alain Van Hout (36) is a Java Software Crafter with a Master in Science (Biology) and experience in academic research concering evolutionary biology. Currently, Alain is working on web applications and API intergrations at the genomics data analysis provider BlueBee (Mechelen), where he combines his background in biology with his passion for software Craftmanship.