Featured Tutor: Josh Lobel, a Creative Problem Solver

The work that I do is mainly design development, or more generally, creative problem solving. I help people figure out how to translate design ideas into design deliverables and I use digital design and fabrication technology to do so. The projects I work on range from graphics and visualization, to prototyping, to large-scale architectural projects. My undergraduate degree is in architecture (B.Arch ‘99 from Cornell University).

I spent the first seven years of my career working at architecture offices of varying size in San Francisco and NYC. I was producing 3D models and visualization from the start of my professional career but after a few years I became very interested in parametric modeling and computational design. That led me to getting my Masters degree from MIT in Computational Design in 2008. After that I moved from Architecture to Engineering for a short while and then to Construction, effectively covering all the bases of the AEC industry. I consider myself a design technologist who works within the AEC industry as opposed to an architect or designer who works with technology. It’s a subtle but important distinction.

In general BIM, or Building Information Model(ing), is a catch-all acronym for the integration of CAD geometry with database information (I’m including both 2D and 3D geometry in my use of the term CAD here). Doing so allows users to define explicit relationships between geometry and (largely) text/character-based information. Doing so expands the ways in which design information can be used to simulate, study and refine a concept prior to construction. BIM software also includes a wide range of productivity tools that make the creation of design deliverables, namely 2D drawing sets and product schedules, more efficient to produce and content-consistent.

In the early days of BIM (2006-ish) the term was used interchangeably with 3D modeling. Now, with the increased sophistication of tools like Revit and the widespread industry adoption of BIM software the term is finally becoming less ambiguous. A result of that is the proliferation of more recent acronyms that are currently in vogue such as VDC (Virtual Design and Construction) and IPD (Integrated Project Delivery).

VDC is the process of combining numerous individual BIM’s into a master model, or Federated Model, which construction management firms typically use to vet and coordinate the work of all the major subcontractors with each other and the architect. The most popular part of this process is clash-detection, which checks to make sure individual construction elements do not overlap, or clash, with each other.

IPD generally refers to the process of having all the major stakeholders, the designers and the builders sharing and exchanging digital information for a project in hopes of identifying and resolving any issues/concerns prior to construction. There are also a lot of contractual and legal motivators involved in IPD. However, all of this still has a long way to go before it works the way advocates claim it will.

It really depends on each person’s interests and goals. The typical roles and responsibilities within firms have been and will continue to become increasingly specialized based on the increasing use and sophistication of digital design and construction technology. That means people with good technical chops might easily become isolated doing one specific thing, which may or may not be enjoyable over time.

I don’t like doing the same thing all the time so I have had, and continue to, work against this for myself. I do so by trying to stay current on software developments and implementation, as well as constantly augmenting my skills. To keep my skills fresh, I come up with relatively small-scale R&D projects which I use to test out new software or work-flows and gauge how those things might integrate into my current work. It’s a good way to vet new software and I think it’s a great way for people to both show off their technical skills as well as their aptitude for innovative seeing, thinking and doing.

Another piece of advice is that in a knowledge economy, make the effort to know what you’re doing (and why). When I was still working for architecture firms I was really dumbstruck by how few people seemed to be questioning why computers were simply being used as digital pencils when the differences between pencil and paper and logic-based digital data structures were like apples and ants (as it turns out, this is something many people had been writing about since the advent of CAD in the 1960’s, but I didn’t know it at the time).

When I went back to school for my Masters degree I initially planned on simply developing my technical skills and become a parametric modeling whiz. I did that (the what part), but along the way I also became interested in the history of CAD/CAM, as a socio-technical phenomena (the why part). I studied not just the technical developments of the software over time but also the social expectations and outcomes of the impact of graphical software on the AEC industry. Doing so has provided me a strong understanding of the fundamentals of CAD/CAM and computer logic in general.

This makes it fairly easy for me to transition between many different platforms without getting caught up in the hype of any particular software while also differentiating myself as a critical thinker with the historical citations to back it up. This analytical/critical perspective makes me effective at both the production and management levels which is extremely attractive to companies that are looking for more than just CAD-monkeys. Creative initiative and critical assessment skills are important for anyone to have who wants to be a leader in this field.

I came out of architecture school in 1999 with some 3D modeling and rendering know-how, which at the time already set me apart from the crowd. Additionally, my interest in 3D modeling was driven by my desire to understand how and why things were built a certain way as opposed to just wanting to make pretty pictures. I would 3D model everything, down to the nuts and bolts, which was not a very render-friendly approach at the time. However, it did help me learn more about construction detailing and the direct impact it has on a design concept. I also became incredibly frustrated with modeling a project and then having to draw it again in 2D. There was also very little quality control imposed by the software (which is still the case with 2D CAD software). Plans, sections and elevations not aligning was irritating enough.

Yes, the work that I do is very detailed for good reason – it has to be. I typically need to produce both design documents as well as fabrication documents. For those who might not be familiar with the difference, design documents represent the intent of overall assemblies whereas fabrication documents instruct fabricators on each and every individual part to be made. When I produce fabrication documents, I effectively “own” the geometry. If there are any mistakes or oversights, I am responsible (financially and otherwise) for correcting the issue and having the parts remade, so it adds a lot of pressure to make sure I get it right.

It is a very different set of challenges and anxieties to those I previously experienced coming from an architectural background. Liability tends heighten your focus on the details. I also typically work on highly customized, one-off projects so I can’t always rely on typical construction details and need to consider how all the parts and pieces will fit together, how they will be delivered to the site, and how they will be installed.

My most challenging project was “Sky/Light v6”, an installation of 46 reflective panels outside the window of a private residence in Manhattan. The challenge was largely of my own making. I had provided fabrication information for two previous prototypes that were built and installed by the client’s contractor. Those prototypes were mainly plywood and fell apart after about a year of being outside in the elements. The client liked the work and asked me to develop a more permanent installation. I saw this as an opportunity to push the envelope a bit and test the theory that digital design and fabrication could allow an individual to play the part of a “master-builder”. I challenged myself to design, fabricate and install the entire thing.

This was also a side project I was doing in addition to my day job, which meant I was only working on it nights and weekends. I also have a family (in fact my second daughter was born about 4 months into the project) and I promised myself and my wife I would not let the project interfere too much with our time together. All that combined made for a very challenging project.

I did the initial design model in Rhino, and then built out the entire fabrication model as a Grasshopper definition in conjunction with Excel. My goal was to keep the fabrication methods as simple as possible – using as many off-the-shelf extruded parts cut to custom lengths as possible. The Grasshopper definition allowed me to evaluate and check that all of the mass-customized parts were resolving correctly within the overall model while simultaneously generating the 2D part profiles for those parts which I had laser or water-jet cut. I was able to output the lengths of all the straight-cut parts optimize those cut-lists through an Excel solver which almost completely eliminated any leftover waste material.

I also compiled a bill of materials in Excel and tracked my hardware orders. I had not done, and/or did not know exactly how, to do most of this when I started so it was a steep and narrow learning curve. It was awesome and a nightmare all at the same time. In the end I had to sub-contract some of the fabrication work (although I still did most of it), and most of the installation work due to time constraints. It was probably both the best and worst work experience I have had so far – great in terms of what I learned, the skills I developed, and how well it turned out; and the worst in terms of the stress and physical exhaustion that I put myself through.

I’ve never been much of a futurist, but in the near term I expect technology developments within the AEC industry will continue to be very “noisy” meaning lots of novelty and little innovation. It’s not that I’m pessimistic, but I’ve studied the history of computer aids to design and construction within the AEC industry and technology has been talked about in largely the same way for the last 50-plus years. For example, the first CAD system, called Sketchpad (which was also the first graphical user interface), was created in the early 1960’s by Ivan Sutherland at MIT. Sketchpad not only used a light-pen as an interface, similar in some respects to what many graphic artists use today, but the software was also parametric, constraint-based, and object-oriented. This was before object-oriented programming even existed!

Consider that against the fact that the widespread use of parametric software within the AEC industry has only happened within the past decade, and that AutoCAD only introduced geometric constraints in 2010. Something just doesn’t add up. I wrote a short article for Linkedin Pulse recently that touches on this with respect to a new company called Flux that came out of Google X labs and is promising to dramatically change the way the AEC industry works. If folks are interested, they can check it out here. On a more upbeat note, I expect (and hope) that the use of 2D drawings as design deliverables will go away and be replaced by fully interactive 3D construction models. The ability to do this already exists and is in fairly widespread use. The most significant impediments to this and other advances becoming more commonplace right now are legal and contractual, not technological.

It’s kind of funny that you ask this, because I never intended to relate that statement to how I design. But there you go, case in point about the ambiguity of communication. The reason I like to talk about ambiguity is that I don’t think it’s possible (or even a good thing necessarily) to overcome ambiguity, at least not where people are involved. Instead I try to work within the morass of ambiguity. I feel that if you accept that communicating ideas is difficult and carries a high degree of ambiguity, it makes you less certain that people are understanding you in the way you intend them to, and more apt to utilize varying forms of communication to tease out any misinterpretations.

One of the reasons I got in to 3D modeling and rendering was that I felt it provided a better means for communicating design and construction information and in a way that would better allow others to “read” and interpreting a set of drawings. I believe that if you can provide someone with visuals that allow them to create their own “mental model” of a project they are more likely to engage their expertise and proactively address any issues they might see. After that, it’s always good to make sure there is plenty of visual documentation exchange.

It’s interesting because much of the early expectations of both CAD and BIM was that the technology would eliminate much of the repetitive work involved with creating and exchanging design information, but it turns out that some of that repetition is extremely useful in that it creates a positive feedback loop which can be very informative.

Back to your first question, I don’t consider myself the type who tries to communicate ideas and emotions through my design work. I see most of my work as creative problem solving which implies creative problem setting. I see what I do more as clarifying a design question and then providing an answer based on programmatic and pragmatic constraints.

When I am faced with a design challenge, I tend to be process-oriented. First I try to clearly state for myself what I am trying to accomplish. That gives me some sense of direction and usually provides a basis for defining constraints and establishing a research idea from which I hope to organize a design process. In that sense, I am influenced by the work of others which I feel followed a similar approach – Gaudi and Cecil Balmond (in conjunction with OMA) would be a couple very obvious and accessible examples.