I’m thrilled to bring this provocative guest post from a fellow architect with strong opinions on how we draw and the importance of traditional methods and tools. Also, if anyone out there with mad cinematographer skills would like to help me make this into a piece for the next AIA Film Challenge, hit me up! We would definitely win.
Greetings! My name is Glorp. It’s quite a culture shock, to say the least, when one is unfrozen and reanimated by a mad scientist some 10,000 years or so after getting iced over during a particularly frosty winter next to a herd of mastodons. As I’m sure you, my fellow architects, are well aware we never truly retire. I wanted to get right back into the swing of things, pick up some new clients, design them a cave of their own, and maybe string together enough projects to get a firm going with some other unfrozen cave people.
I was thankful to quickly find a group of architects who helped me get up to speed with what architecture practice means in the 21st century. You don’t have to worry about me being out of touch or irrelevant — these architects explained that the proper, indeed the dominant, style of today is called “classical” and is based upon design concepts first developed in Europe a couple thousand years ago (boy, am I glad that today’s pace of progress isn’t much faster than it was back at the dawn of the Holocene). They helped me learn the modern, high-tech drawing and drafting techniques of today as well; so I know all about t-squares, vellum, and pencils, all good there.
At this point, I’ve given these pencils and vellum a shot, but they are vastly inferior to the techniques of my time. In fact, this new pencil-on-paper technology really interferes with a caveman architect’s ability to properly design, which is the last thing an architect wants from their tools. Perhaps the nutty clans who designed and built those ugly, new-fangled stick-and-leaf huts may like the precision of these modern tools, but they’re not for us real architects.
With the pencil and vellum, There’s no longer a need to carefully consider one’s next move of the hand because these tools take all of the thought out of that act and you can simply erase if you make a mistake. None of this elevates the architect to the respected position of finest artist in the cave. Since we cave architects didn’t do much else thousands of years ago, where does that leave us!?
Your pencils, with their synthesized graphite encased in precise, machine-honed wood and tipped with rubber to conveniently undo what was just laid down are cold and completely disconnected from my traditional tools. Do you think this stupid graphite is going to stand the test of time like my generation’s work? Hell no! What are you going to do if you erase something only to later realize that you needed it? You can’t get it back now, it’s gone forever! FAIL!
I’ll be continuing to use my clay and stones on cave walls because, unlike today’s high-tech architects, I understand that being an architect is all about design concepts freely flowing through one’s entire body to convey ideas in beautiful cave-drawn form in unison with nature. The clay ochre tipped flint stone comes from Mother Earth, just like me, and is an extension of my body in the creative process. You have no such unity with these damn machine-made pencils so you do not have real architecture, it’s that simple.
I hate to cut this short, but I have someone coming to the cave shortly to help me get all these words on the cave wall into something called the Internet for you to see. Thanks, and please join me in a return to traditional drawing techniques.
Who’s ready for a listicle!? It’s that time of year when everyone everywhere is reminiscing on the best whatevers of the year. Of course, I’m getting in on that action with a list of the top ten most-read articles of 2020, the year of ALL CAPS triumphant return. Here we go…
It’s no secret that I ❤️ Smartsheet and I was happy to see that you all liked this series on building the absolute best friggin’ system for managing rollout development! (seriously, all other systems suck and this one rules)
The Paycheck Protection Program was one of the few morsels of good news we had in 2020…until we saw who was taking all that dough. In my tabloid-esque look at who got what in architecture, we see that there’s some architects out there making Mike Brady look downright poor!
There’s no question that THE STORY of 2020 for the AEC software world was the angry architecture firms’ open letter to Autodesk. It was real tip-of-the-iceberg shit. One of my favorite things I wrote this year was this article, so I’m glad you guys liked it too.
…and now, the most-read story of 2020 at ALL CAPS…
This was one of those article ideas I felt really satisfied with, and it was a lot of fun to think back on all these titles. I had to dust off a lot of old spreadsheets and notes to find all the failed software. Every architect knows the struggle of finding good digital tools to get the job done.
Thanks for reading! In my look back at the site’s statistics I found one article that doesn’t have a single view! I’m not saying which one because now I’m paranoid that it’s really bad! 😂
My favorite movie of 2020 was Crip Camp. This documentary follows the lives of a group of disabled teenagers and young adults who met at a summer camp for the disabled in the 1970s and went on to form the movement for universal access and rights for disabled Americans that eventually led to passage of the Americans with Disabilities Act (ADA) of 1990. For me, the ADA is the greatest design movement of the 20th century, as it caused sweeping changes to the ways civil engineers and architects design sites and buildings — it opened up these spaces to everyone for the first time in our country’s history. It’s easy to forget what our built environment was like before ADA, and the numbers of architects who practiced in that pre-ADA world are shrinking every year. In Crip Camp, the inequalities of the pre-ADA world are laid out in deeply personal terms by the campers. We learn about the lived experiences of people with a wide variety of disabilities too — it’s not all about wheelchair access. The filmmakers do such a good job capturing the importance of this overlooked movement for equality that Crip Camp should be required viewing for all architects and architecture students.
The movie also got me thinking about an aspect of practice that I’ve seen a lot of newcomers to architecture struggle with over the years, and that’s how to juggle the overlapping accessibility requirements of the ADA with state and local codes and regulations on accessibility. I see a lot of people mix up these overlapping requirements when they’re starting out, and most frequently, the mistake is that the state and local codes get followed to the detriment of ADA’s requirements. Sometimes, that’s okay if the state and local codes are more stringent, but most of the overlapping requirements represent a little bit of this code and a little bit of that ADA requirement — you’ve got to blend them together in your design to make sure you meet all the regulations.
Here’s how I look at ADA versus state and local codes and regulations:
For those I’ve mentored over the years I use this approach to explain the regulations of accessible design, and it seems to help people get past their misunderstanding of this topic more quickly.
Beyond the dry topic of law, code, and regulation you have the larger landscape of universal design. It’s rarely enough to simply implement accessibility law, code, and regulation. The most impactful part of Crip Camp for me as an architect was getting to see the discussions the campers had about their frustrations not just with the built environment, but with the way the world perceived them and their value to society. The design insights provided by these conversations provide powerful lessons in universal design for architects. It’s certainly changed the way I think about the access and usability of space, especially the weight of those considerations versus everything else one considers when turning a program into a design.
The absurdity for me began back about a decade ago — I can’t remember the exact year, but I’ll never forget the sequence of events. A client reached out to have me send a bunch of content from the drawings we had prepared for them over the years to a guy at Autodesk. After what I can only assume based on personal experiences was a full-court-press sales job, the client had decided to migrate their design criteria from AutoCAD to Revit and Autodesk was going to build them a template and a library of content on top of signing them up for rent-a-license annual fees.
In a rational world, this would be no big deal for me as my firm had already been producing this client’s projects using a BIM authoring tool for several years at that time. They would be catching up to me and maybe they actually start using the ever more powerful BIMs my team was producing. In turn, I could help them out with sophisticated content that was already up and running. Side note: since our contract obligated us to provide what some well-meaning, but ultimately poorly informed attorney wrote in as “AutoCad R.12 files” we simply exported our beautiful, smart BIM to dumb DWG files for the client’s records up to this point. The BIM was really just a more efficient design and production tool for us at that time.
But 21st century BIM practitioners do not operate in a rational world; we work in a world of daily absurdity. My offer of BIM content was rebuffed, most likely because Autodesk had mostly walled off any of Revit’s potential model geometry sharing capabilities ever since it acquired the software from its original developers. All they wanted was some DWGs, and to this day it still makes me laugh that my content went from Archicad to AutoCAD to gawd-knows-what to Revit. That. Is. Absurd.
I don’t mean to make this all about Autodesk walling off the rest of the industry either — even though that’s exactly what they do. The real point, the real absurdity, is the basic approach to BIM collaboration happening here.
My area of practice as an architect focuses on working with chain concepts on rollout development, especially with restaurants and retailers developing dozens or even hundreds of locations nationally here in the US every year, so that’s the perspective I’m writing from with this article. In conversations with other BIM practitioners, I’ve found that we chain architects share the same absurdity with those who work on larger one-off projects like campuses, stadiums, and high-rise buildings where the client has an extensive and very specific EIR.
Back to that BIM collaboration approach. Basically, every chain that’s migrated from CAD to BIM in the US takes the same approach, which is, “hey, we’re using Revit (insert specific version number here) to make a shit-ton of content for you, so you have to use Revit (insert same specific version number as client here) and use all of this content as-is — oh, and that’s super easy ’cause Autodesk said so. So get it done faster and cheaper too.”
This. Is. Absurd.
If I approached someone (maybe not you, as if you’re reading this you’re probably thoroughly tainted by the absurdity already) and said they would be spoon-fed a bunch of stuff for their job…
…and this stuff was often cumbersome or counterintuitive to their workflows, (imagine fixing the same errors with each new version of the content, or reformatting the same stuff over and over with each new design made from the content) but they couldn’t do anything about that because this stuff had to stay in the same format and version it came in even if the rest of their company was working in a different format and/or version since the content had no backwards or cross-platform compatibility…
…and receiving this stuff, and working for the client would tether them to really expensive and often flawed software — the only software that can use this restrictive format — and that software stops working if they stop paying in every year — even though other software does all the same stuff and more and better for less money, oh and it has perpetual licenses…
…and despite all that nonsense, everything they create for their client will be useless in a few years because this software will be unable to open the old files, so they’ll have to do the old work all over again in a newer version of the same shitty software if the project ever gets revisited by the client…
…they would probably stop to think and say, “well, how much am I making off this?”
FAIR QUESTION! The answer is certainly no more than you did already and there will be pressure to do it all for less since the client is investing so much effort in spoon-feeding you, even though their content is slowing you down. Also, what is your sanity and freedom to operate as you see fit worth to you?
…they would then agree to do the work anyway! Why? Remember: ThIsiSaBsUrD¡
Getting back to us, the tainted-by-absurdity BIM community now. A/E firms sign up for this — we line right up to participate in the absurdity. We need the work and we don’t want to let down our clients, even if they’re headed down an ill-advised path that will fuck over our G&A budget while giving our staff (especially BIM managers) migraines. There are also people amongst us who think this is a good idea because they don’t know better, so they’ll sign up for the work too. This is what we do as poor sap architects after all, this is our lot in life. Embrace the absurd!
When Did It Become Absurd?
The story of how it became absurd is a brief one. It’s not complicated. Autodesk acquisition-ed itself into the BIM paradigm and used that change to avoid the mistake it made with AutoCAD in not having a locked-down proprietary file format. Then Autodesk seasoned that shit stew with some restrictive versioning and a shift to renting instead of owning the software licenses. We poor sap architects made like Tennille and told our Captain, “do it to me one more time!”
But here’s the real kicker, in our (I’m using this possessive determiner to be nice, keep me otherwise out of this) rush to Revit, most made the same mistake that always happens at paradigm shifts in our profession and in this case, didn’t really change their CAD workflows for the BIM world they were living in now. A few users found their way to little bim and enjoyed new levels of production automation over CAD, but not much more than that. And here in the US there was virtually no Information in BIMs early on (and it’s not much better today).
This brings us back to chain concepts (and clients with large-scale one-off projects). Autodesk sells these corporate entities on flashy BIM doing fancy Information-driven shit, but they only get to little bim (the content I’ve seen made by Autodesk is, well…crap) and settle for getting automatic elevations and basic stuff like that. Keeping those old CAD workflows on top of all this, the corporate entities (our clients) push out templates and libraries to their consultants, but it’s not like it was with DWGs where people could use a variety of versions of AutoCAD or even other CAD tools (looking at you, Microstation and Vectorworks lovers, or any of the multitude of other software that can run with DWGs), you have to use the exact same version of Revit now as your client and absolutely nothing else. Side note: the acrobatics these companies and their consultants go through when the company decides it’s time to use a new version of Revit since it’s not backward compatible are truly something, and bring plenty of unintended consequences with them. Another thing the client doesn’t realize is that unlike DWGs or DXFs, eventually these RVT files will age out, and unless you have and old computer sitting around that can run that old version of Revit, you’ll be sitting on gigabytes of worthless files…unless (per Autodesk support) you also happened to save out an IFC file with that RVT back whenever (warm up that time machine). But no one reads that part. I know because no one involved in the decision making about using Revit at these corporations seems to know much about IFCs at all in the conversations I’ve had with them over the years.
We don’t stop to consider what you actually need for legacy BIMs, which is just the friggin’ BIM itself and not all the CD set content that proprietary formats include (at least not the editable original versions of it); and that these BIMs may not be needed for ten years or longer (ten years is a common lease term for the retail industry and that’s often when old designs get revisited). Who’s to say what we’ll be using to do our work in a decade? I certainly don’t want a bloated legacy file, as all that bloat guarantees a crash on open. Thus far Autodesk hasn’t done jack shit to make sure their customers can use those RVTs that many years later. It’s enough to make an openBIM advocate roll their eyes so hard they get stuck in the back of their head.
What Keeps Us Embracing the Absurd?
Fear, for one thing. We’ve been in the walled garden long enough to be worried that if we step outside we may not be able to get back in again. But on a more technical level, there’s the divergent objectives of openBIM that create confusion and frustration for people new to it that are just trying to be free to author BIMs using the tools and workflows and content that they control. This part is where some of the openBIM folks will get irritated with me, and that’s okay. We’re not letting perfect, standards-driven, Information-loaded deliverables get in the way at this point (though I do earnestly want us all to get there someday). Let’s just get ourselves decoupled from proprietary files and dumb CAD workflows for now.
If you dive into IFC, you’ll quickly get that it’s all about the ‘I’ in BIM — the Information. But in the beginning when you’re starting out with it, you really just want to be able to share model geometry with another party because that’s all anyone’s been doing to this point in time with all their RVTs and RTEs and RFAs and whatever else. This graphical side of the conversation is largely ignored in conversations about openBIM because those convos are conducted by the more advanced BIM practitioners who are simply focusing on their interests. Yes, these early exchanges will be messy and could be better with some Information coordination, but we’ll get there, just hang on. While we all need to be doing Information-driven BIM, we have to start by just making sure we can share the damn model geometry, even if it’s not perfect (it wasn’t perfect in the RVT either, so there’s that too). That’s step one for this particular project type and it’s the impure, ugly truth.
On the consultant side of things, I find that you need to keep things short and sweet with the client, as you’re lucky just to get a moment to talk about a different way of doing things. What I’ll do is discuss the IFC format and IFC viewers, then we’ll exchange some small, simple test IFC geometry that we can each look at the test geometry in the viewers and our BIM authoring tools. Now we understand how the geometry translates across platforms and make adjustments as needed. There’s often frustration for the client when they don’t see something exactly like the RVTs they’ve been looking at for years. I equate these feelings to the frustration one feels when initially learning a BIM authoring tool at that moment when they feel like it’s all too much work, too many settings to fiddle with, and it was just easier with CAD (but substitute RVT files for CAD in this case). I’ll explain to the client that it’s just different and that the BIM tools have settings to better control/automate imports and exports to make the software do the work for them. Like when initially learning BIM, just keep at out and you’ll grow to appreciate it for what it is: a better way of working because it lets all of us work the way we choose that’s best for us. There’s another conversation to be had with the client about the forward compatibility and reliability of the IFC format over time, and this convo goes pretty smooth as people don’t want to lose that work due to the passage of time.
I’ve found you need to give the teams doing IFC model geometry exchange time to get comfortable before you get into the Information part of those IFC-based BIMs, and some of those Information conversations will just start happening naturally when they realize the Information drives the model. After exchanging IFCs for a while, people start to make requests of each other with regard to model elements and maybe even some properties of the elements. From there, people see possibilities in working together to customize the BIM via IFCs neutral exchange and then you can start talking about including (or more accurately, cleaning up the mess of) Information embedded in that model geometry. People are shocked to find out that all the Information they’ve ever wanted from their BIM has already been asked for a zillion times in the past and that someone invented a system for reliably exchanging that Information (why hello, COBie!) and that there’s software to automate the movement of that Information between parties. It’s all baby steps to make sure we don’t lose anyone or anything along the way.
Will We Ever Not Be Absurd?
You can see how it’s easier when the client just does things openly from the start, as that trickles down to the consulting professionals and then everybody’s on board. It takes longer and requires more effort to push uphill with change from the consulting professional side of the content exchange.
The same mindset that resists adopting national CAD and BIM standards kind of applies here. For example, we all know our personal standards are best, so we don’t pause to think about a world in which we never have to spend time configuring and troubleshooting software for our own standards because the national ones are baked right into the default settings. It’s a similar kind of resistance that says it’s easier if I spoon-feed everything to those who work for me and we all do it my way in my software using my content — take all the thinking and choice out of it, you know…
Another obstacle to these efforts is the software and its limitations (mostly this is Autodesk, but not exclusively). A lot of Information exchange is hindered when developers don’t implement reliable import/export methods for standards-based information. I see Autodesk joined ODA, so maybe this will change, but I won’t hold my breath. Right now, Autodesk does a lot to muddy or just outright block the road for imported geometry to become a Family, which is a constant source of frustration and wasted time in my efforts to work openly amongst teams using a variety of BIM platforms. We find workarounds that allow us to support our openBIM efforts, but it’s clunky and inefficient. There’s no question that we need something slightly less shitty from Autodesk here.
Anyway, back to converting RFAs for use outside Revit just to be able to do some architecture. Have an absurd day!
A little while ago I wrote this thread on Twitter about how chefs with a dream need to approach design and construction of their first restaurant (or one of their first few, for that matter). I was triggered by a story in the local news about yet another chef teaming up with a firm that has a long history of shaming chefs into spending more money than they should (or even have) on elaborate, crazy expensive designs with almost no project management to steer those designs to reality on schedule and on budget.
Now I’m triggered to expand on my Twitter thread by a tweet from Carl Quintanilla about restaurant chains gaining while independents are losing during this pandemic-induced recession. Not to digress (too much), but what it’s really about regardless of whether we’re talking chains or independents is places that serve amazing food (or even just so-so food) and make it effortless to get delivered or picked up curbside will kick ass right now, no matter if they’re big or small. For example, independent fine dining will suffer if they turn their nose up at this notion of delivery/takeout. Or big chain fast/casual will suffer if they don’t quickly pivot to a tightly integrated delivery experiences with phone apps and fast, reliable service. Almost everyone will suffer this winter, so we need to float restaurants during these months of shitty weather with bailouts too. Just give the people what they want…in a pandemic without any bullshit: restaurant food without the whole going into the restaurant part of it. Anyhoo…
First Thing: The Space You’re Going Into Costs More Than Just the Rent
Setting aside the number one most important rule of real estate (location), the space you’re renting for your restaurant needs to be able to accommodate a restaurant. That’s potentially easier if it’s already been a restaurant in the past, even if the last tenant wasn’t a restaurant. I say potentially because it needs to have the infrastructure in place (presently or at a time in the past) specific to YOUR restaurant — and that infrastructure is driven by your menu, so your architect can help figure out what you’ll need based on what you’re serving. If you’re cooking at all, then like 99% of what fucks up your budget if you pick a space that doesn’t lend itself to restaurants is cooking exhaust — getting all the grease-laden smoke from cooking to the outside. This kind of exhaust is super expensive to design, construct, and maintain, so the shorter the duct going from the cooking appliances to the outside, the better off your budget will be. Spaces that don’t lend themselves to short, straightforward runs of grease exhaust duct get insanely expensive real quick. Another space-related money trap is who’s below your tenant space. If it’s anyone other than dirt and worms, it gets spendy to put in underfloor plumbing and make sure your very wet kitchen doesn’t leak into the neighbors below.
There’s all sorts of things about a space that can make it cheap and easy to build out or expensive and difficult. It’s not sexy, and it gets in the way when all you want to do is start putting your dreams “on paper” with your architect, but having your architect perform a thorough assessment of the premises is like having a mechanic look over a used car that you want to buy before you pull out your wallet. So do this before signing a lease if you can, that way you can talk the landlord down on rent or get other concessions based on what your architect discovers. The architect will also do a regulatory assessment to understand all the red tape that you’ll need to cut through to get this restaurant to the finish line — research that saves you a ton of time down the line when a contractor is engaged and the big bucks are getting spent on the job site. All of this research is the most important (if not glamorous) step in the entire development process. Do it!
Second Thing: Everything You Don’t Want to Talk/Think About is Most Important
More unsexy stuff: plumbing, HVAC, and electrical. Restaurants have gobs of this stuff (only hospitals have more and we all know how expensive they are). Almost your entire budget will be gobbled up by the guts of your restaurant. Cold, hard fact right there. This is another place where if you aren’t careful about how your restaurant gets laid out in the space you could screw your budget up before construction even starts. The most important money-saving moves you can make with expensive plumbing, HVAC, and electrical will be related to the initial design of the restaurant. Never let the contractor design this stuff for you, because not only does that disconnect expensive stuff from a design process that could save money, but very few contractors have the foresight to understand the consequences of their own on-site design decisions, which will have them coming back to you for more moolah after they’ve realized their design choices aren’t going to fit the budget and/or schedule. You always want these systems engineered up front while the restaurant is being designed by your architect. That’s smart spending.
None of this has anything to do with finishes or layout function. An experienced restaurant architect will be able to juggle all the expensive guts while considering finishes and layout function in a way that preserves your budget by planning in great detail up front while things are cheap to do “on paper” so to speak, rather than figuring it out on the fly while you have a dozen or more laborers on site charging you thousands per day even when they have to sit around waiting for a decision to be made. This leads us to the next thing…
Third Thing: Applying Detailed Planning and Thought to Bare Minimum Documentation
Just like everything else, you need to be smart with how you spend your money on architecture and engineering services. We’ve discussed having your architect perform thorough assessments of the premises and regulatory conditions, and this is where you want to concentrate your professional services dollars because these services are all about uncovering as many of the potential money pits and schedule bombs as possible up front so that the rest of the project can be delivered with these hazards in mind and without excuses later on that blow up budget and/or schedule.
But you still need some documentation to go and get a permit and health department plan approval. This is where your architect can develop a bare minimum set of drawings to get you through these pre-construction entitlements. All of the important knowledge gained from the assessments can inform a simple, spartan architectural floor plan, reflected ceiling plan, and room finish schedule. The engineers will add a plumbing plan, HVAC plan, and a power and lighting plan with necessary schedules. That room finish schedule and reflected ceiling plan will include bare minimum finishes for the kitchen and restrooms to appease the health department, with all other finishes to be determined later. Spatially, the architect can still layout an interesting front-of-house in anticipation of finishes. Light fixtures can also be placed based on some desired level of illumination and then left to be specified later. Basically, the last thing that will happen on your restaurant project from a design perspective will be selection of finishes, furniture, and light fixtures because we’ll back into what you can afford for those things after two big milestones: 1.) signing a contract with a GC; and 2.) getting through the rough-in stage of construction. Getting through framing and utility rough-ins is a critical stage of restaurant construction because if there are any more unpleasant surprises to be uncovered once construction starts, they’ll likely all of been found (and more importantly, paid for) by this time. Then, and only then, do you have a sense of what kind of money you’ll have left over for all the fun stuff you envisioned when you first had the idea to open your own restaurant.
A quick note on what happens in between finishing those bare minimum construction documents and starting construction. You’ll go and secure your permits and approvals yourself and you’ll do that feeling well-informed thanks to that regulatory assessment your architect did a while back. At the same time the permitting is happening you’ll want to bid out your project to GCs. Talk to your architect about the pros and cons of having them involved in your bidding process. It all depends on your comfort level and willingness to not bend on the contract after your GC is underway with construction. Sometimes it’s best to have your architect go over bids with a fine tooth comb and make sure there are no omissions or other surprises while also qualifying the GCs. Other times, it’s better to have the owner play “dumb but firm” and if a GC comes back after contract execution saying they didn’t include something that owner can force their hand — it all depends on who you are and how willing you are to be firm.
Fourth Thing: Everything Else That Wasn’t Important Earlier in the Development Process
What the bare minimum construction documentation does is embed all the intelligence gained from detailed research into a quick and cheap set of documentation that can be quickly permitted and built. In a worst case scenario, you use up your entire budget just getting to the point in development of having a built out space with a raw dining room, but you’ll have an operating restaurant — even if you have to start delivery only or fill the dining room with card tables and folding chairs sitting on bare concrete like a garage, this joint will be up and running and able to generate revenue — let your great food and hospitality speak for itself.
But it’s more likely you’ll have a little bit to spend on finishes and furnishings. In exchange for a meal or three at your new joint, your architect would be happy to steer you towards selections that are appropriate to whatever’s left of your budget and schedule at this point. The best part is that this is all stuff you can likely order direct and even install yourself if you have to in order to save time and money. Because your architect planned everything so carefully up to this point, you’ll get good results with their guidance to get you over the finish line too.
In Conclusion: Don’t Fall for the Trap
The trap is anyone: architect, contractor, investor, whoever — that focuses you on the daydreamy part of your restaurant (think: sexy dining rooms with stainless- and copper-clad exhibition cooking lines roaring away in the background) rather than the harsh reality that this shit is expensive; and no, we’re not talking about the contract quality imported furniture (though that’s expensive too). The most important thing when you’re starting out is to get open fast so you can get cooking so you can get revenue so you can stay open. Don’t screw up the opportunity before you serve that first meal because of poor choices in the development process. Let an experienced restaurant architect help you avoid the pitfalls.
Everything in the process outlined here can be done quickly and inexpensively. Remember: the less you have to spend, the more carefully you have to consider and plan out each design decision up front.
This thread on Twitter caught my attention as being exactly the same, confounding question as the whole do architects need to be “good at math” question that I recently wrote about.
Architecture and music are interesting bedmates, and some day I’ll write in depth on this topic, but one part of the aforementioned thread is stuck in my mind and I’m hoping that writing this article will help dislodge it: the question of what kind of music is conducive to writing specifications.
It’s of course a question that can only be answered subjectively. Over the years, I’ve provided on-the-job crash courses in specification writing to coworkers and I’ve never touched upon the music I think would be supportive of this type of technical writing. I infrequently have music on when writing specifications because I’m a very active music listener, so I have to be careful about the kind of music I choose to listen to while doing other tasks, especially when it comes to the tasks of the practice of architecture. It’s too easy for me to get absorbed in the music listening at the expense of the architecture-ing if I’m not careful. But I do listen to music for a lot of tasks and I appreciate the intellectual exercise of finding ideal music for the task of writing specifications.
Spec’s are unexciting, yet important. They’re extremely detailed and technical. Specifications are black and white, with no gray area — literally and figuratively. This kind of work requires focus and concentration, but also something to keep the writer engaged and alert. It’s these characteristics of the task that must drive my choice in music.
I’m thinking of something that’s not too concrete, that would be distracting for the way my brain consumes music. In fact, I’m not sure it could even be all that beat-driven. The sounds need to be soft and relaxing, with occasional brief changes in tempo and/or loudness to check in with me.
The first music I tried was what came to mind as I was thinking this through for the article. Pole’s debut trio of albums from 1998 — more specifically, I played the second album from the trio, “2” on 12” vinyl through my home stereo system. I thought this would be the perfect match, but I didn’t even listen to my own requirements as outlined above. It’s a great album but far too glitchy for proper spec writing.
I had to halt the experiment for a day as I couldn’t think of what else to play and felt frustrated, as I had my heart set on that Pole record. Then I thought of an album I got this summer and have been thinking about a lot. I played it and did some technical writing updates for my BIM template and it was, in fact, perfect. This time the source music was in MP3s which went through a DAC to the studio monitors I keep in my office which provided warm, intimate sound to fill up the room and keep me focused on my spec-writing.
The album? Julianna Barwick’s “Healing is a Miracle”, which was released earlier this year. Julianna’s vocal loops and sweeps of low-frequency, room-shaking bass are what I recommend when it’s time to write some specs. I think her entire discography would be appropriate to this technical task as well. I’ll be trying some other albums and different media formats from her catalogue to confirm my assumption. Going forward, if I ever have to train anyone else in spec writing, I’ll include Julianna’s record in that training too.
If you decide to take me up on this recommendation, don’t go and stream this work — buy the damn record and support Julianna’s amazing music properly. Happy spec writing.
My last article has me thinking a lot about minimalism. I like to master a small handful of critical software titles and try to stretch the limits of what can be done rather than relying on a long list of different specialized titles that my projects have to pass through in order to create everything I need.
An unanticipated benefit of the minimalist approach is that it can save money in this age of the software-as-a-subscription pricing model, which is probably why I thought about this after that last article’s focus on software costs. It’s become important to me to weigh the amount of stuff I can accomplish with a given software title to its subscription cost. So the higher the cost, the more I better be able to do with that software. Even if a software title did just one thing that was vitally important, but cost a lot, I would rather test alternatives that had Swiss army knife qualities. A minimalist needs their software’s capabilities to be maximalist in order to have a minimalist roster of software titles.
This raises an important point: minimalism doesn’t mean software complacency. I’m always researching the software landscape and testing titles I find interesting. This part of minimalism is a lot of work, which aligns nicely with minimalist design — it’s also a lot of work to make things look simple and…minimal. Over time my standards for what graduates from testing to use on actual projects have become more stringent because of my desire to be a minimalist. Not to digress, but open standards and open file formats are a must for minimalists, as they allow you to quickly and easily change out software without needing even more software just to make that change happen.
New design technologies introduce new software — potential clutter. For example, virtual reality and augmented reality have a boatload of software titles to make everything work. Further complicating efforts at minimalism is time it takes new design technology to sort itself out in the market. Which major player will acquire the hot new startup? When will this new hardware come down in price? Which of these two nearly identical technologies will become the standard we all use? Minimalists must learn to slow down and wait for the dust to settle before committing to new technology. Minimalists are less early adopters and more early observers.
Business software adds a layer of complexity to a minimalist software approach. You inevitably need at least one or two pieces of software dedicated solely to business rather than design. This is a tough pill to swallow for us minimalists, but there’s joy to be found in winnowing the biz titles down to the absolute bare minimum too.
For a business with more than one employee, minimalism has its benefits when it comes to training on both the software and the workflows. I’ve found that a lean software library typically leads to nice clean minimalist workflows too.
I feel stressed when I see other architects and designers using a lot of software, even if they’re getting impressive results. All that extra software is clutter to me. What do you think about my minimalist approach?
All those lists that well-meaning architects make of their favorite software become outdated quickly. I thought this would be a more interesting way to talk about personal software preferences than the usual “what I use” software lists out there. These obits will be limited to software I actually used on real projects. Software that never made it out of my testing phase was dead to me before it ever really got going — plus any list I make of software I’ve merely tested would be long as hell!
Before you dig into these, be sure to open this song in another tab and leave it playing in the background as you read. Have a tissue handy, this is going to be emotional. Deep breath…here we go…
Man oh man were you a dysfunctional piece of shit when I met you. I stuck with you though, and you got better with each version. One thing that never improved though was the TurboGrafx16-like graphics of your 3D window…or your ridiculous cost of ownership…or your inability to work well with others…or how slow you were in handling larger BIMs…you know what!? You’re still a dysfunctional piece of shit.
Survived By: Archicad
A mainstay of my architecture practice for many years. I invested time and energy mastering its programming language and managing its deployments. It rewarded that investment with limited functionality and inexplicable crashes and network license errors (it was really the only reason to ever reboot an NT server). You won’t be missed.🖕🏻
Survived By: AutoCAD’s web version and DraftSight (the only reason anything replaced it is so I can validate DWG and DXF exports from Archicad)
Architectural Desktop 1997-1998
You were a bloated version of AutoCAD that thought it could do something resembling BIM, but without the reliability or lowered effort. Good riddance.
Survived By: No next of kin…
3D Studio MAX 1998-2006
I won’t miss how slow this software was nor how unpredictable its output could be sometimes. It tied up endless hours of processing time with its renders that I look back on and laugh. Like its late cousin, AutoCAD, network reliability was horrible as well.
Survived By: Lightworks (Archicad)
It came on the scene like a breath of three-dimensional fresh air and swept us all off our feet with its beautiful, simple, intuitive interface…but then you had to edit/revise what you just modeled. The rest, I’m afraid, is ancient history.
Survived By: Archicad
Piranesi was a revelation. Its EPix technology was (and still kind of is) a very cool way to edit depth in 2D imagery. You were quick and easy for making renderings, but maybe a little too specialized for your own good.
Survived By: Lightworks
Illustrator & Photoshop 1998-2018
When architects need these two capable titles, they really need them. I relied on Illustrator and Photoshop for all sorts of tasks that helped make me and my work look good over the years. I want them to remember (up in heaven) that it was never about them, it was about their creator, Adobe, who’s a total asshole that I hate.
Survived By: Affinity’s Designer & Photo
I only liked you because you were built into Archicad. Everything else about you was clunky and unintuitive.
Survived By: CineRender
Ditto what I said for Lightworks, but at least your were slightly faster.
Survived By: Twinmotion
I loved you and you were the best WYSIWYG web tool ever…and then Adobe bought Macromedia and was like, “Hey, everybody! Use this bloated piece of shit instead!” You are missed.
Survived By: WordPress
I doubt any word processor will ever be able to handle templates as slick as you. Alas, the age of email made me adopt Office (and Word along with it). You will always be remembered and loved though.
Survived By: Word
No one emulated a beige box PC as fast as you, and the best part was I could just shut you down and make that beige box disappear.
Survived By: No next of kin (I just avoid Wintel software nowadays)
You were certainly reliable, if not attractive. Updating your database was an epic undertaking that consumed hours of my life.
Survived By: ArchiOffice
ArchiOffice was a breath of fresh air relative to the dinosaur that was Wind2. It was built upon FileMaker’s database technology…then its developer migrated to MySQL…and sadly ArchiOffice succumbed to its injuries.
Survived By: Toggl
I never liked you, but you knew that. I was all too happy to send you packing.
Survived By: Revu
I liked what you were capable of on a good day, but you became even slower than Acrobat, and that’s really saying something.
Survived By: TBD (still testing my options)
I definitely tested a lot more software on these portable devices than I ever did on the desktop. Very few apps ever make it out of testing and into my tablet/smartphone workflows though.
Still the 🐐 CAD app for smartphones. I managed to keep this old beauty running on Visors and Treos well into the iPhone era. No one to this day could interface with a Leica DISTO like you, my beloved. Always remembered. Always loved. Let’s pour one out for ZipCAD.
Survived By: DISTO Sketch
You were kind of helpful at a time when being able to open Office files on a mobile device was groundbreaking. Viewing was your specialty, editing was your downfall.
Survived By: Word, Excel, PowerPoint (iOS versions)
I thought you were really great, but then I realized I needed something much simpler. Goodbye.
Survived By: Linea Sketch
It’s funny how much in this realm is absolute garbage.
Your interface looked like web 0.1 technology and you were slow af.
Survived By: Accruent
While far from perfect, I generally admired IBM’s efforts…until I met you, that is.
Survived By: Smartsheet
I always wondered how you were so much slower than all the other cloud services using Amazon S3, then I remembered Autodesk made you.
Survived By: Smartsheet
What have I learned from all of this software death over the decades? Don’t get seduced by software that promises to work miracles, as very, very few miracle-workers ever live up to their potential and several even end up making more work for you. Most software is simply okay, and as long as its reasonably priced and reliable, you should rely more on your own imagination and creativity with that software to make it work miracles for you. (also, this statement is not to be misconstrued by Luddites who think it’s okay to still use CAD, it’s not, get help)
In my two–part series on distributing design criteria via Smartsheet I explained how the heart of the process was a direct pipeline of information between Smartsheet and the architects’ and engineers’ BIM authoring tools. In my example of this I used Archicad and I wanted to share some more detail about how to make Archicad’s property import/export functionality work with Smartsheet.
Archicad has been able to import and export property data via Excel spreadsheets for several versions now and it’s a very slick way to use information to drive your BIM workflows with external vendors, subcontractors, and anyone else who communicates product and design specifications via spreadsheets. Since Smartsheet is spreadsheet-based and can import/export Excel files (among other file types), it too can be used to communicate property data with Archicad with just a couple extra steps to help all the data make the journey.
If you haven’t already used this feature of Archicad, read about it here in the Help Center before you dig into the Smartsheet workflow.
Now, here’s how property information transfer between Archicad and Smartsheet works:
Just like you normally would, set up your properties and schedules in Archicad and then export them from each schedule you want to share with Smartsheet. This will give you XLSX files for each export.
You can open the exported XLSX file and notice that row 1 in the spreadsheet is collapsed by Archicad. This row contains the GUIDs, which are the Midi-Chlorians of Archicad, who in this case are working behind the scenes to make things from outside of Archicad match up with things inside. You shouldn’t alter row 1 or do anything with it, so close the file without saving. It’s just important to know for later on that row 1 is there, and to note that row 2 is the headers from your Archicad schedule.
Next launch Smartsheet and import the XLSX file. When you do that you’re prompted to select a row from the XLSX file to make the Column Headers in Smartsheet. You want to select row 2 here. In Smartsheet the header row doesn’t have a row number, which is different from Excel. This difference means the old Excel row 1 with all those GUIDs is row 1 in your newly imported sheet in Smartsheet.
During the import process you’re also prompted by Smartsheet for which column to make the Primary Column in Smartsheet (Primary Columns have special functions that we don’t need here, but you’ll need to select one nonetheless). Select column 1 from the Excel spreadsheet, which is the column containing the GUIDs for each row in the schedule.
Lock the Primary Column and row 1 in your new sheet in Smartsheet so no one messes with those while working on the rest of the schedule. Then go about filling out or changing cells as needed.
When you’re ready to export the sheet from Smartsheet back into an XLSX file, do so like you normally would from Smartsheet’s File pull-down menu.
Open the exported XLSX file in Excel. Here, we’ll need to move that GUID row that we made the Column Headers in Smartsheet from row 2 in the XLSX file back to row 1. Once we do that, the XLSX file is ready to be used by Archicad.
These are some images of the steps in the process noted above that may be helpful in understanding the workflow.
That’s it! A switcheroo of row 1 as it goes from the XLSX file into Smartsheet and then back into an XLSX file again is the key to this workflow. Hopefully we see a Smartsheet plug-in for Archicad someday that just does this for us automatically, but until then, this is how it’s done. Happy data-transferring!
In Part 1 we looked at how Smartsheet can serve as a tool to help organize and disseminate design criteria for companies doing rollout development of their concept. We discussed how vitally important it is for the design criteria being referenced by external consultants like architects and engineers to be current and accurate.
In Part 2 we’ll cover how to build a pipeline of current and accurate design criteria between Smartsheet and the BIM authoring tool used by the architects and engineers. This pipeline of information is the automated magic that makes this workflow superior to everything that came before.
You’ll recall from Part 1 that we loaded up sheets with specifications in a schedule format where each row represented an individual fixture, furnishing, or piece of equipment. BIM content corresponding to each row was attached to that row. Smartsheet’s push notifications let external consultants and vendors know that changes have been made and are ready for download and export. With this functionality in mind, we’ll establish the information pipeline to the BIM. In the example of this workflow, we’ll use the architect as the external consultant and Archicad as the BIM authoring tool, but the workflow is essentially the same for other consultants and other BIM authoring tools.
Step 1: Notifications & Downloads
Once the organization makes changes (including additions and/or deletions) on a given schedule sheet, the architect receives an email notification highlighting the change from Smartsheet. The architect then opens the sheet and goes to the changes (if desired, the company can even have Smartsheet highlight the changed cells in the sheet itself for ease of identification) to download the new BIM content if applicable. If the change is to the specifications, the architect exports an XLS file of the schedule from Smartsheet as well.
Step 2: Updating the BIM with Changed BIM Content
The architect will add the BIM content to the library for their BIM, retiring old content if applicable. The updated library is reloaded and the new content gets verified in the BIM, including aligning the new content’s ID and classification with the corresponding schedule in the BIM. Next, the architect can then begin updating the scheduled specifications for this new BIM content.
Step 3: Updating the BIM with Changed Specifications
The architect imports the data from XLS file from Smartsheet into the BIM to update the properties of the BIM content with the changed scheduling information. Schedules in the BIM then automatically update with the changes, with no manual data entry required
This workflow is the same whether the architect is updating their template or a live project. The three step process can be completed in just a few minutes as well.
Another great feature of this workflow is that the company can allow the vendors who provide the stuff in the Smartsheet schedules to update those schedules and their attachments directly which effectively extends the information pipeline from the architect directly to the source of the information, further reducing opportunities for errors and omissions.
Let’s be brutally honest here, no one likes doing prototypical updates — it’s boring af — so the more of it that we can leave to technology like we see in this workflow, the better off we all are. Having it be more accurate and timely is an added bonus. Distribution of a chain company’s design criteria is just one use of this workflow, so I’m hopeful that as more jump on board with it, we can begin leveraging Smartsheet APIs to have the workflow be even more automated than what’s shown here — like a plug-in for the BIM authoring tool that grabs all the content and data straight from Smartsheet. Bring it on!