The Architect is the artist. He lives at the intersection of art (the abstract) and engineering (the reality).
He has has a vision for the future and finds a way to express that vision through technology.
The Architect’s vision, and the richness of that vision, is informed through their life knowledge and experience.
The Architect then has the job of conveying the vision in a manner that is understandable to the developer in order to realize his vision (e.g. Creation of a product).
The probability of success of the product coming to life and having the envisioned utility must lose as little communication signal as possible such that the Developer can code the vision into a real product, and adopt that vision.
The loss of signal is based on the architects skill at conveying his thoughts to the developer. And so, the architect may draw diagrams, write paragraphs, and write software to describe the implementation through a prototype.
The Developer is the scribe, similar to how a lawyer is a contract writer. Writing software is analogous to writing a legal contract, whereby typically a lawyer drafts a legal document that conveys the intent of the business person that hired them.
In writing software, the developer aims to achieve the architect’s vision through writing the most concise software that satisfies the most amount of conditions (e.g. exceptions) while using the least amount of code.
The developer is responsible for handling the minutiae of getting the computers to do what was envisioned. The functionality of the software
The architect can become the developer, and at times the developer can become the architect as they see eye to eye with the product’s intent. However, when a new project is born, it is the Architect who establishes the vision of where a project is meant to go. Talented developers with high emotional intelligence, can sometimes take an incomplete vision by an architect and fill in the gaps (thus making them more of an architect than developer at this point).
The Architect may not understand the details of the code, and they don’t have to. They set the direction and overarching ‘architecture’ of the project. It is the Developer who has to figure out how to implement the product through software and transcribe the vision into code and modules that .
The quality of the software is determined by the skill of the Developer in fashioning the modules of the software — similar to a lawyer architecting the sections of a contract. We could consider this architecture as well, however, its more lower level, and is unrelated to the overall architecture of a project.
What happens when a new developer picks up a piece of code of a project that was initially created by an Architect or another developer?
That Developer has to understand the intent of the software. They make assumptions and sometimes those assumptions are out of alignment with what the Architect envisioned unless the Architect is there to shepherd the developers.
If the Architect leaves a project, the end product the will be drastically different from what was envisioned.
It is likely that the project will vere from the architect’s intent, unless the project is simple or the architect is there to Shepard the realization of the implementation.
Satoshi Nakamoto was the architect. We have yet to see Satoshi’s vision realized.