Architecture as a System of Prohibitions

illustration

In the operating theatre of the previous chapter it is hard to make a mistake, and in 2009 this was measured. A group of researchers working under the auspices of the World Health Organization introduced in eight hospitals in eight cities, from Seattle and London to New Delhi and Ifakara in Tanzania, a short list of checks that the surgical team goes through aloud before anaesthesia, before the incision and before the patient is wheeled out of the theatre. Mortality after surgery fell from one and a half percent to 0.8, and complications from eleven percent to seven. Nobody invented new drugs or instruments in that time, the doctors stayed the same, and the only thing that changed was that they began checking a few obvious things against a list.

If you read the list, what strikes you is that almost all of it consists of prohibitions, however politely worded. Do not begin until the patient has confirmed his name and what exactly is going to be operated on. Do not make the incision until the site has been marked, because surgeons, hard as it is to believe, sometimes operate on the wrong leg. Do not close until the swabs and instruments have been counted, because they are sometimes left inside. The checklist tells the surgeon almost nothing about how to operate, since the surgeon knows that himself. It says what must not happen in the operating theatre under any circumstances.

The architecture of programs, seen through the eyes of an agent, works the same way.

---

illustration

For most people the word “architecture” brings to mind a handsome diagram: rectangles, arrows between them, labels like “payment service” and “customer database,” all of it printed on a large sheet and hanging on an office wall where nobody has read it in a long time. Engineers define it more precisely. Grady Booch, one of the people who invented today’s ways of describing how programs are built, wrote in 2006 that architecture represents the significant design decisions that shape a system, where significance is measured by the cost of change. The colour of a button is not part of the architecture; it is changed in a minute. How the data about clients is organised is part of it, because changing that takes weeks.

While people were writing programs, most of the architecture lived in their heads. A newcomer to a team kept hearing, in his first months, the phrase “we don’t do it that way here”: we have one login, the client table is never created a second time, old migrations are not touched. Gradually he absorbed these rules along with a thousand others that nobody had written down, and six months later he was the one telling newcomers “we don’t do it that way here.” Architecture was passed on much as customs are passed on in a village, and it lived in the memory of the people who had lived in that village a long time.