I learned automation by drawing donut stores (AKA “Architecture & Donuts”)

It all started with donuts

I used to eat a lot of donuts. And I really mean a lot. In high school I was averaging 6 a day.

But I have an excuse! At the time I was working for the architect responsible for many of the Tim Horton's donut stores in the province. (I didn't say it was a good excuse.)

This story is about biting off more than you can chew, and somehow getting away with it.

I was a co-op student at a very small architecture office of ~4 people. We had a lot of work. Much more than we should have had for the small team that we were.

The architect -- Andy Bruce, a gruff fellow in his late 40s at the time -- had fully bought into the idea of using computers for architectural drawings. That's the norm today, but it wasn't in 1988. AutoCAD had only been invented about 5 years earlier. A state of the art CAD computer then was an Intel 80386 with a math co-processor. Specs were pitiful compared to today: 4 MB of RAM and a 40 MB hard drive. Most of us worked on 14" monitors and one lucky person had a 15" monitor.

So how did this small non-technical team of architects use very new technology to produce an outsized volume of work?

The owner really cared about efficiency

Andy described his company's work as falling into one of two categories:

• Things you HAVE to do (the boring "bread and butter" work)
• Things you WANT to do (creative, energizing projects)

If you can make the boring work simpler, easier and cheaper, that leaves more time and money for the creative and interesting work. That was the simple driving incentive behind it.

So how do you make the business of architecture more efficient?

Efficiency is an intentional decision

"It's not the tool. It's how you use it."

Most architecture offices didn't use AutoCAD until the mid-1990s. And even then, many used it simply as a replacement for pencil and paper. People in the profession saw CAD as either a toy, or something they feared and wanted to avoid. (I.e., the same pattern that meets most new technologies.)

Anecdotally, I remember university professors in my architecture program explicitly deriding ideas and designs that had been drawn using CAD vs those which hadn't. Why? Some foo-foo ideas about the "creative spirit" and the "cold inhumanity" about work produced using anything digital.

Anyways, somehow Andy saw the opportunities to change how we think about producing work.

He recognized some of the fundamental steps that can be taken with a CAD system when considering efficiency. For example:

• Reusability
• Templates
• Automation

If you've ever been a software developer, this is going to sound very familiar.

Reusability

You may think each set of architecture drawings is completely custom -- unique for each particular building. But look a little closer and you'll realize that while that's generally accurate, the drawings are actually an assemblage -- a composition -- of many smaller parts.

For example, there are many doors on a floor plan. While they may have slightly different sizes and properties (left-swing, right-swing, fire-rating, solid vs hollow, name plate, etc.) they are all still variations of the same shapes: a rectangle and an arc.

It's not just doors. Electrical symbols, bathroom fixtures, office desks, detail bubbles, etc. There's lots of repetition in architectural drawings. Meaning, lots of opportunity for reuse.

Use the "Next" and "Previous" buttons below the image to toggle the reusable symbols in the floor plan.

Do we need to redraw these each time?

No, of course not. From the beginning AutoCAD had a solution for this problem. It's the "block" system. You take a collection of lines, group them, give them a name, and then reuse them over and over again. And if you need to make a change to that master "block" later you can. When you do, every instance in the drawing will automatically get updated as well.

That gets us started with the bare-minimum. The basics. Reusable pieces. Andy's office made full use of this concept in 1988. Offices I worked at over 10 years later were still just using CAD as a "digital pencil" without any of the other benefits.

So that's step 1. Many of the elements in our drawings can be reused. In fact, we had a standard library of reusable items that we'd share across all projects. A "component library" if you will.

A sample partial set of reusable AutoCAD blocks (circa 1988) for site and building plans.

Templates

We mostly worked on donut stores. At the time, all baking was done in the stores. All the specialized equipment in the kitchens had to be drawn. That was mostly taken care of with the reusable blocks we described earlier.

But the kitchen had other design challenges. It's a small factory of a sort, and the arrangement and location of elements mattered for the bakers. It wasn't necessarily a trivial problem.

And, it wasn't something we wanted to solve for every new store. It was tedious and time-consuming. What was Andy's solution?

We created a few kitchen design templates. The effort of "solving" the kitchen was encapsulated in a few reusable options to choose from. The general size and shape of the building, along with entrance and exit locations gave us easy solutions for at least 80-90% of new stores. And where it didn't, we would take a template as a base and modify it.

But Andy didn't stop with the kitchen.

He later realized that generally, there were about 4 different donut store layouts covering most of our site scenarios. He had us create template variations for entire stores. That meant the vast majority of effort to create a set of architectural drawings for a new store was already covered by the templates.

By templating the donut store project type, we were an order of magnitude faster. And our quality was consistent.

• Good: A reusable door block (e.g., a component)
• Better: A kitchen module (e.g., a collection of components)
• Best: A full building template (e.g., a boilerplate or project-level template)

Andy realized the opportunity for optimization. He took advantage of the technology to create that optimization. His small office could then produce a volume of work normally requiring a much larger team, in less time.

In "modern times" like today (2023), you'd think this must be the way all architecture firms work. They don't.

Remember, it's not the tool. It's how you use it.

Automation

One of my first programming jobs (as a high-school co-op architecture student) was creating an automation tool for Andy. This wasn't specifically for the donut stores, but for any AutoCAD project. Especially very large projects like schools and office buildings.

Even with all the reusable blocks and templates, a set of architectural drawings still requires lots of manual work.

For example, it's common to have a door and window schedule in the drawings. This is a table that lists every door and window required along with their details.

An example of a very small door schedule. Some schedules may have over 100 entries.

How does that get created? Somebody manually counts each door and window in a drawing, and writes it down. You want to do this near the end of the project because if you add or change a door or window later, you need to remember to update the schedule as well.

Is that error-prone and tedious? Definitely.

Andy's insight was recognizing the CAD drawing is a database of objects with properties.

Remember those reusable blocks we talked about before? Doors, windows, detail bubbles, etc. Every block can also have "properties" attached to it.

For example, we could create a door block in AutoCAD with these properties:

You add the properties when you insert a new door block, and can edit them later.

Why is it important to add data to the blocks?

Because now we can write a program (in Lisp) that finds all doors in the drawing and automatically creates a door schedule. It can:

• Find all doors in the drawing
• Sort them by door number
• Ensure the door types are valid
• Automatically create the schedule table
• Add all details about each door in the schedule

We can start using the drawing like a database. And that means we can automate queries about the drawing. For example, the number and details about doors and windows.

Not only does it save a lot of tedious work, it reduces the risk of making a mistake.

What did the client think?

I think they thought we had some magic technology. They were always trying to get the original digital CAD drawings (which was uncommon at the time). We were always trying to find ways to "protect" or "lock" them so they couldn't reuse our blocks and templates.

But really, the thing they were missing wasn't the technology. It was the thought process and philosophy towards how we used the technology.

This is applicable beyond architecture

After leaving the architecture field, I worked at software product and technology marketing agencies for over 20 years. I've seen the "donut store" problem (and opportunity) so many times, in so many places. The challenges -- and solutions -- are extremely common in technology and software development. They're not new concepts.

How often do we succeed at solving them day-to-day?

There's often an imperative need for "perfection" in technology solutions. Templating is hard; we need to think about edge cases, design exceptions, etc. We hold our nose and look the other way when we're asked to use an "impure" solution. We'd rather build something "perfect" from scratch rather than use something built by someone else.

Purity, creative "uniqueness", not-invented-here syndrome, lack-of-absolute perfection... these are all reasons I've seen as to why we generally fail to modularize and improve agency technology solutions.

It's very often a case of "letting perfect be the enemy of good" (and often it's just about someone's ego).

It's nice to be reminded that if a bunch of non-tech architects from 30 years could figure this out, there's no excuse as to why technology professionals in 2023 can't. (Sorry, rant over.)

And finally... in memoriam

It's hard to overstate how much of the way I approach things today is driven by what I learned from Andy Bruce.

In a profession that has historically been shy about technology, not only was he in full support of it, he knew how to use it to full advantage. This wasn't a case of being in the right place at the right time. It was a mindset and a philosophy, deliberately put into practice.

I remember him once describing what the "correct" act of drawing in AutoCAD should be. "You draw one line. That's it. Then you extend, offset, rotate, trim and copy that line. Keep doing that until your drawing is complete."

Andy's approach taught me the fundamentals about identifying opportunities for improvement and automation in day-to-day work. Both big and small things. He'd be very comfortable with computer science principles such as DRY.

Unfortunately, Andy passed away in early 2023. He was one of my earliest mentors, and the lessons I learned from him applied well beyond the bounds of architecture.

Thanks Andy.

// ka

You might also be interested in...

How I learn a new programming language Category: programming My First Website HTML from 1994 Category: tech Bash Shell Tips - find Category: tech