Software Architecture vs Software Engineering
My thoughts on an age-old question, what is considered architecture, what is considered engineering?
I recently had an exchange with a software architect where I performed code analysis for their codebase. I presented to them a couple of suggestions on where code improvements could be made and my reasons for making those suggestions. I was surprisingly met with a blank face. The fellow architect confessed they do not understand much of the programming language’s semantics, and thus did not quite grasp much of my reasoning. Interestingly they are actually in charge of designing systems using that particular programming language.
This had me thinking. What is the difference between software architecture and software engineering? Should software architects be software engineers first and foremost, and have at least a certain level of familiarity with the language itself, before moving on to architecting systems using that language? Should engineers have a say in architecture and contribute to it?
A personal anecdote: I have been on both sides of the table, I was a software architect at one point in my career and I am currently a software engineer in my company. I have always been intrigued by how bigger companies make clear-cut distinctions between software architects and engineers.
Even worse, I have seen very binary thinking among the two groups: architects who think coding is beneath them; I have also seen engineers who think architecture is not their problem. I have always been baffled by this mentality.
Let’s take a step back and try to understand what a software architect is supposed to do. A quick Google search gives me this as the first result:
What is a software architect?
A software architect makes high-level design choices and frames technical standards. This might include tools, software coding standards, or platforms to be used. To be effective, a software architect needs broad (and deep) technical knowledge to make good decisions. However, technical knowledge isn’t enough. They also have to have the soft skills to manage projects and people. Let’s review the soft skills and the hard skills needed.
Other Google search results also show similarly how architects are expected to have a certain level of technical knowledge. Of course, it would be impossible for anyone to know every existing technology inside out. To rephrase what the expectations towards a software architect are,
Are software architects expected to master the programming languages that they are designing systems for?
I would argue yes. Software engineering and software architecture should be considered two sides of the same coin. But many companies seem to think otherwise.
Why is architecture important to a software engineer
I tend to think of software engineers as ‘having their feet on the ground’. Their main responsibility is writing code, ideally bug-free, correct code. Having sensible architecture, whether it is decided by architects or collectively by fellow engineers, helps with maintainability, which in turn lets engineers write code more easily.
Architecture gives software ‘forms/patterns’, whereas code gives software its ‘contents’. Studies have shown that humans are excellent at recognising patterns and having patterns lowers the cognitive complexity of comprehending its contents. Having repeatable patterns in place usually results in safer code because engineers can then direct more of their attention to the business domain and the functional correctness of their code instead of constantly worrying about architectural concerns, which usually are cross-cutting and permeate throughout the codebase.
Although the words architecture and maintainability are subjective in nature, the presence of deliberate and thoughtful architecture within a piece of software should guide engineers into falling into the pit of success, meaning the most obvious and straightforward way of engineering is already, by default, the architecturally most optimal way.
People also rarely talk about delivering good ergonomics or user experience to engineers, because most would think these ‘big words’ are only aimed at non-technical end users, but having good architecture is akin to giving the engineer the best ergonomics for the engineer to succeed, making everyone’s job easier, wouldn’t you agree?
That is why I strongly urge software engineers to have a voice in software architecture if your organisation insists on separating the two. It also helps development teams by removing siloed knowledge and training engineers to have a holistic mindset of the complete technical solution.
Why is engineering important to a software architect
Now let’s take off our engineering hats and put on our architect hats. Ask ourselves, if architecture is indeed the ‘form’ in contrast to the ‘content’, does it really make sense to design software that has form but not content? I think it is quite obvious the answer is no.
Perhaps it can be better explained using a metaphor—I play Muay Thai. I am what most people would call a weekend warrior because I don’t train to fight. I do Muay Thai once a week purely for its health benefits and its tremendous efficiency as a sport. In Muay Thai, there are no fixed ‘forms’. Muay Thai is also known as the science of eight limbs — punches, kicks, knees, elbows, one of each on each side—you are free to combine whatever you learnt in your combos during spars and fights. There are no rules that say you can’t do two left kicks in succession, only tradeoffs. Muay Thai is all about ‘content’, ‘form’ always takes a second priority.
Compared with Taekwondo, another martial art I did when I was very young, is the complete opposite of Muay Thai. I remember fondly taking belt exams where I had to perform a ‘form’ in front of the instructors and other students. A Taekwondo ‘form’ consists of a set of fixed punches and kicks and is designed to test the student’s ability to learn new techniques and memorise choreographed strikes. You are expected to learn it by heart and perform these forms verbatim during your exam. Taekwando is about ‘form’, ‘content’ takes a backseat.
At this point, I think most readers can guess where this is leading to. ‘Forms’ and ‘content’ are both important in their own rights. There is no one thing superior to the other. They are the yin and yang. They complement each other.
As a software architect, your job should be to understand how to build the ‘content’ of the software, ‘form’ a container around the contents, and build boundaries and remove them to adapt to the content. Without knowing what the contents are, how can one know what containers to build?
One can argue an architect can also ‘form’ arbitrarily big containers to contain every possible piece of software ‘content’ an organisation is foreseen to build. A noble goal indeed but this also inevitably leads to leaky abstractions, where the metaphorical container, supposed to generalise recurring patterns in a codebase, becomes too abstract to the point that there are a lot of exceptions because codebases are just slightly different.
Trying to dictate how software should be designed with arbitrary rules without considering the engineering team’s skills, dynamics, and culture is also a recipe for disaster.
Software architecture and engineering look like two very distinct disciplines with little overlap. I hope this article convinced you otherwise. Thank you for taking the time to read!
