Software architects and engineers or just artisans?
Have you been tinkering whether creating software is an art or just an engineering or perhaps those are just two parts of the same thing?
The answer might be obvious, that it always is just an engineering but the reality is much more complex. After all, people been creating buildings for thousands years and for millennia without distinction between an architect and engineers, a distinction from a role of an artisan is a concept of modern times, as a mean to address complexity in building construction.
Reasons for a design
Our human brains have cognitive and creative limits, with small discrepancies between individuals, so when thinking about how to create software, we consciously or unconsciously use shortcuts, analogies, or so called patterns. That was quite well summed up by Douglas Hofstadter in I Am a Strange Loop:
Mature human brains are constantly trying to reduce the complexity of what they perceive, and this means that they are constantly trying to get unfamiliar, complex patterns made of many symbols that have been freshly activated in concert to trigger just one familiar pre-existing symbol (or a very small set of them). In fact, that’s the main business of human brains — to take a complex situation and to put one’s finger on what matters in it, to distill from an initial welter of sensations and ideas what a situation really is about. To spot the gist […]
Sometimes those patterns are well defined, sometimes it’s even hard to describe them with words. Nevertheless, this basic cognitive function of a brain is what is employed by architects to create complex forms but as Alexander Christopher said in his Notes on the Synthesis of Form:
What does make design a problem in real world cases is that we are trying to make a diagram for forces whose field we do not understand.
For Christopher, design is a process of calibration between context, things that surround the desired object, and a form, desired object itself, in order to find the best fit.
Designing as a craft
Let us think of a way to find a best fit for a program to write that needs to transmit high amounts of data. We may have multiple of options at hand but we can list down relations between context and the form first to find the best fit.
In that way, we could create almost unlimited amount of requirements, so because of that, we need to create a list of criteria that distinguishes possible solutions between each other. Because of that we are able to analyze vast amount of examples. After all, when comparing OSS projects on GitHub, we don’t look at the amount of forks a project have as this characteristic might not reflect well popularity of a project (we rather look at the amount of stars).
The above problem can be defined as a search problem. There is a set of possible solutions where we just need to find one that suits best. At the same time, though the process of searching and reviewing many examples of various approaches, we apply a good dialectical approach and because of that, on one hand we move from subjectivity to objectivity and the amount of thesis and antithesis allows us to usher synthesis, as shown below:
As an outcome, better understanding of a problem is achieved, we might redefine the problem once we learn more about the context, as Slavoj Žižek mentioned in Less Than Nothing:
Common sense tells us that there are true and false solutions to every problem; for Deleuze, on the contrary, there are no definitive solutions to problems, solutions are just repeated attempts to deal with the problem, with its impossible-real. Problems themselves, not solutions, are true or false. Each solution not only reacts to “its” problem, but retroactively redefines it, formulating it from within its own specific horizon. Which is why the problem is universal and the solutions or answers are particular. Deleuze is here unexpectedly close to Hegel: for Hegel […] each specific form [..] simply proposes a solution, redefining the problem itself. The passage to the next “higher” stage of the dialectical process occurs precisely when, instead of continuing to search for a solution, we problematize the problem itself, abandoning its terms […] A problem is thus not only “subjective,” not just epistemological, a problem for the subject who tries to solve it; it is stricto sensu ontological, inscribed into the thing itself: the structure of reality is “problematic.”
What if we work on a unique project, where we don’t have many examples to understand the problem and find the best solution? It actually is a creative process, where a brain tries to create a set of inputs based on an output. It is something even DNNs are capable of, as it’s very simple to run trained networks in reverse. It means that actually everyone can do that as it is a basic function of a brain but how to perform that function in an IT project?
Designing as a necessity
We can see those techniques seem at first sight departed from a regular job of a software engineer but should there be a separate person that handle that? Gregor Hohpe defines 4 different modes of operation of an architect in a team/project:
- Benevolent dictator — a despotic micromanager defines how things should be designed
- Primus inter pares — there is a separate role of an architect that works as a servant for a team to keep the architecture alive
- Architecture without architects — team members work together on architecture
- The inmates running the asylum — team members don’t care how the system they create works as a whole
On top of that, some companies might be putting architects in pre-sales teams, that try to create solutions for customers, to have so called solutions architects. Such organizations might focus on making sure that engineers create a product that looks convincible whereas the architects try to actually actually deliver a project to customers. It departs from the above differentiation as it might happen that an architect will work on their own, in separation from other engineers or rather, only with sales and legal teams.
Be agile artisans
Let’s put the sales teams aside and focus on engineering teams, that after all, are the ones that drive the project. Even though there could be some main distinctions how to organise people in teams, it all depends on the actual people composition there is in a team.
As stressed by Pierre Pureur, everybody in a team should have architecture skills, that is, everyone’s voice should be heard. Every person provides unique point of view on a problem that given software tries to solve.
What we should strive for is to keep being artisans, people that will focus on both, creative parts of a software design as well as the logical analysis of problems that software tries to solve. Only if it’s needed from an organisational perspective, a split can be created but only when it’s needed to address technical complexity.
