My degree is a B.Sc. in architectural engineering, from Islamic Azad University in Qom. My first job, in 2016, was cutting website templates with Gulp, Sass and Jade. People sometimes ask whether the degree was wasted. It wasn’t. I use it every week; I just draw boxes and arrows instead of walls.
Five ideas made the trip from buildings to software almost unchanged.
1. Start from the brief, not the facade
An architect’s first document is the brief: who will use the building, for what, how many, when. The facade comes last. In software the brief is the domain — the language the users speak and the rules they live by. Domain-driven design is, more or less, the discipline of reading the brief before you draw.
2. Loads travel down; dependencies should point in
Every structure has a load path: the roof rests on beams, beams on columns, columns on foundations. Nothing holds up the thing above it by accident. Hexagonal architecture is the same idea for code. The domain is the foundation and depends on nothing. Everything else rests on it, and you can change the furniture without touching the footings.
3. Circulation is the design
In a plan, corridors and stairs decide how people move and where they meet. Bad circulation ruins beautiful rooms. In a product, the flows — sign-up, checkout, a nurse’s day — are the circulation. I sketch the journeys before the screens, and the screens before the database.
4. Every building has a service core
Lifts, shafts, plumbing and wiring are grouped in a core so the rest of the floor can be open. Software has the same core: config, logging, auth, file storage, health checks. Put it in one place — for me, a starter kit — so each product team gets an open floor.
5. Drawings are for the builders
Construction drawings are not art. They exist so that someone on site, in bad light, builds the right thing. Decision records, diagrams and READMEs are the same: written for the person who will change the code at a bad moment, not for the review meeting.
The part that did not transfer
Buildings are expensive to change, so architects try to be right the first time. Software is cheap to change, so trying to be right the first time is usually the mistake. The skill I had to learn was the opposite one: ship the smallest honest version, watch how people use it, and redraw.
