Superusers see what they do in terms of providing value to others. By engaging Superusers, productivity is increased and value added, via agile processes and automating repetitive processes. This chapter looks at how Superusers provide an improved user experience, by easing use and accessibility of tools, while connecting tools, people, and processes, with an aim to reduce user pain points. The chapter concludes looking at how Superusers seek out and leverage new technologies, and participate in software development, tool creation, and the potential commercialization of these tools.
There are incredible career opportunities brought about by leveraging the new tools. LMN Architects Principal Stephen Van Dyck remembers pulling George Shaw, a partner at LMN, aside in 2010, right before they started the Design/Build phase of their Cleveland project. Van Dyck recalls:
I had an idea that we could link Grasshopper to Revit to achieve our design intent. We had a really fast delivery timeline and in order to execute our concept, the design and documentation needed to essentially progress in parallel. We knew that there was an API that had just been expanded in Revit, and that with a little bit of coding, we could make these two powerful tools come together. I sure has hell couldn’t do the coding myself, but I had faith that one of our founding Tech Studio members, Dan Belcher, could figure it out.
Dan got his head into it and wrote a plug-in we called Cricket. And it worked well for that project, and enabled us to do some pretty amazing things in a really tight schedule and budget. The first product of that tool was the façade for the Cleveland Center for Global Health Innovation, which we built all-up for $65 per square foot inside to out. I, and the whole delivery team, would credit our design and collaboration process – enabled by that plug-in – to be a key driver in the value we achieved. That plug-in later evolved to become Lyrebird, which Tim Logan, who used to be at LMN, and now with HKS LINE, developed.
As Van Dyck makes clear, the genesis of it all was his conversation with George, and convincing the leadership of the office to explore Revit after years of committing to Bentley. “That was one of those moments where I just knew barely enough on the technical side, and could leverage relationships to suggest a strategic shift, and then get the right people at the table to help make it happen,” says Van Dyck.
The value Superusers provide to their teams and firm is not as clear-cut as just delivering code or connecting tools. So what do we mean by delivering value? How is that measured, and what value specifically do Superusers deliver to their teams and firms that employ them? Project Architect at DLR Group Ryan Cameron is interested in providing value to architecture – value created with better design through increased collaboration, new techniques, and time for reflection. To re-quote Cameron:
Future designers will need all three if they strive to create a better world. They’re all dependent on one another. There’s an order of operation that almost has to happen with these. It’s the dewy kind of collaboration that happens between everybody. What are the best techniques you’ve used to fish-out those best design ideas? You need to do this as quickly as you can to give your brain a chance to catch up with the speed that’s out there now. That’s the part that is the time for reflection. You really need all three. It’s stepping back and describing the process as simply as possible. It’s a bunch of people in a room, scrambling, mad, doing all kinds of sketches, or modeling, whatever the process is. It’s enhanced by technology.
Increased productivity and value via agile processes
People hired from other industries can have an influence, perhaps even improve upon, firm processes and culture. They bring to the AEC industry mindsets and methodologies that help Superusers – and the firms themselves – succeed. Lean, Agile and Scrum are a few that have been introduced into firms in recent years. Woods Bagot principal Shane Burger says:
Just two weeks ago when I was in our Sydney office, I presented to our design leadership and our CEO. One of the conversations I brought up as part of that was not just lean but thinking about lean management from a global business perspective. But specifically talking about Agile. I walked them through what sort of things does a Scrum-based approach with an Agile provide a project team that is beyond a concern about a project management system? But something that actually yields benefit to the designers. This is a conversation that came up a while ago. My team has been using Jira for its team management for a while but not in a full Scrum format. More of a Kanban style. Rather than specific sprints. But by bringing in people with software development backgrounds it has brought this conversation up.
Burger has two software developers, one in Sydney and one in Melbourne, who are continuing to develop a design dialogue – or design sharing – system within the office. Burger explains:
It’s almost like a Pinterest for projects. We developed that based on a Scrum approach with regular sprints every two weeks now for almost two years. I’ve been quite used to it now. We’re running Jira in that space. We run our team meetings the regular way. We don’t have the daily standups because doing that across three geographic locations would have been a bit difficult. That said, we did start to bring on some of those approaches within the core design technology team about nine months ago. We are using it in some way within our team. Now it’s moving into a second-level conversation asking, what can we learn from their approach to potentially apply this to projects? I’m at the very beginning stages of that conversation. I’m trying to walk people through a narrative of what does it mean to do this? What are the regular events that happen along the course of a week or every other week tied to the sprint schedule, and what sorts of benefits do they potentially provide a project team?
This is something that has been changing at Woods Bagot. “Moving out this mentality that there is a single workflow – or single collection of tools – or a single approach that will solve most of the problems that you will run into. For me, it’s a lot about agility,” says Burger. He continues:
Both in terms of the toolset you use but also very much the methodology. And having a conversation at the very beginning that says, OK, we need to get from point A to point B, we think we know what point B looks like, but we’re not really sure. We at least know that we need to fulfill our contractual obligations. There are 10,000 paths in between so let’s discuss where we go first, and make sure we’re able, in an agile way, to flow from one place to another. If we need to wire up something new that we’ve not done before, let’s jump into that and learn it. Or bring in the people we need at that moment. It’s not a clean process. It’s always a messy process. A certain amount of embracing of that is quite important. Understanding at any point we can augment our design process the way that we want to. We can customize what we want to experience and design. It need not be what the software developers – Autodesk or McNeel or anybody – have handed us, and it need not be the way that you’ve done it for 20 or 30 years that you brought over from SOM or NBBJ or anybody. By its nature, it needs to be as collaborative as possible. The process needs to be developed by the team, customized for whatever the project needs.
Figure 4.1
Relevance Pyramid: Relevant to whom? (2018) Credit: Deutsch Insights.
Superusers create value in at least four ways: they automate processes; they make tools easier to use, more accessible, reducing pain points, providing a better user experience; they connect tools, people, and processes via interoperability; and they seek out new technologies, increasing productivity via software development and tool creation. Let’s look at each in order.
Automating processes
Automation is not new. For the design professions, it goes back at least to the advent of CAD. Fernando Araujo, Associate Principal, Studio Leader, and Technical Director of Solomon Cordwell Buenz (SCB) was hand drafting and then at some point picked up CAD. At the time, there was CAD, and there was CAD the way Fernando Araujo did it. This was the early- to mid-1990s and he would hit the macros on the keyboard with his left hand, and the whole building seemingly instantly materialized.
Superusers isn’t about people who literally use software better or faster than others. One can find outliers at industry events winning contests for doing that. Instead of getting people to work faster, one might purposefully slow people down – to get them to think before they act: that’s a Superuser tactic or skill. But back in the day, at the introduction of CAD to the industry, it was literally the ability to use a new tool and make the most of it, and Fernando Araujo was someone who had that ability. Araujo admits:
That was probably me. Back at that time CAD was fairly new and we had perhaps five or eight workstations. It was a limited amount of workstations so most of the people were still drafting by hand, especially the senior folks. But my being a more junior person at the time, and interested in technology, I came there and knew a lot about CAD. And I did. I was pretty good with the macros as I do recall. I still use them if I use CAD. I use the short macros, I don’t use the pull downs, because it’s just a lot faster to type in a command, a two letter command and then move as opposed to finding it on pull down. Yeah, I do remember that.
So, in a sense Fernando Araujo was automating with the macros before anyone else was really automating in architecture. He took a relatively nascent tool and made it really sing and perform. What enabled him to do that? Was it his education at the earlier Mies program at IIT, and afterwards working at Mies’s successor firm? What would lead one to think – beyond his interest in technology – that by using two fingers on the keyboard in CAD, he’d become the equivalent of a team of one putting a building together? What was behind that? Araujo explains:
Going back to when I was at Fujikawa Johnson, CAD was a new thing. My boss was so skeptical about CAD. He thought it was just the biggest waste of time, yet everybody was investigating it so we’d experiment with it. There were so many senior people and knew so much more than I did, but they weren’t interested at all in learning or using CAD. I saw it as an opportunity and it seemed interesting to me. I got sucked into the idea of the technology, even back then, of being able to do the work of multiple people much more quickly. I just jumped in. I thought, I’m going to learn this, and it will help me find my place and be of value to the firm, and help the firm advance. It was a good opportunity for me as a young person with a little bit of knowledge to really experiment and help the firm push a little bit and see where we could go with CAD, which was the big thing back then.
Which takes us to automation today and Superusers automating things. CAD aside, some if not most of what design technologists do today didn’t exist in the early 2000s. Hiram Rodriguez, Computational Design Group Leader at Thornton Tomasetti, was not aware of the various visual scripting platforms until he was in school. “It is just insane when we do retrofits of old buildings, and you get to see the construction set, they really crammed all the data in a few sheets,” says Rodriguez. He continues:
Whereas today, current technology is furthering our ability to generate complex shapes and forms, that need complex construction sets. It is hard for me to visualize this profession 20 years ago without access to tools like Rhino, Revit and other cloud-based platforms that allow geometry to be “easily” translated to other platforms. Within TT, we encourage the use of new technology. We have found that by using and trying different technologies and techniques, we have a better understanding of the built world. It has allowed us to approach design from different perspectives and deliver a higher standard of data.
For example, Rodriguez only had two days to come up with a few roof iterations for a competition and the only way to coordinate all the iterations was by using Grasshopper. He says:
The tool allowed us to generate BIM data, steel tonnage and surface roof area for ETFE. This was crucial for us. We end up winning the competition, which allow others to see the power of these new processes within the firm. In the near future, it is going to become even easier to use these tools, but if we don’t create tools that are user-friendly, they will never be adopted. We should also focus on teaching how to generate consumable scripts. No one wants to open a massive Grasshopper script. Can we think about creating plug-ins or add-ons instead?
Computational designers look for any part of the work process that’s repeatable, assess what repeatable tasks are worth automating, and which should be left as they are. “Sometimes the problem, to automate a task is too much of an effort, it’s better to chop it up and break it into segments that you can tackle,” explains Rodriguez. “Because it would take half a year’s worth of the developer’s time to develop a tool. Then is it really worth it? That’s always the question.” Rodriguez continues:
You always want to approach visual scripting in terms of tasks or parts that function together, because that is the whole purpose of these platforms, especially in Grasshopper or Dynamo. As you build these complex systems you need to start thinking how the structure functions in real life. You don’t want to build secondary systems when your primary systems have not been rationalized. The script should be flexible so that you can break those elements into major elements that are going to control smaller elements and then you start focusing down on those elements and their relationships. This is crucial when building complex form relationships for any project in Grasshopper or Dynamo.
“When people see for the first time how quickly you can emulate a design configuration with minimum input, I hear the phrase, ‘You’re just going to automate the whole profession out of a job!’” says Ryan Cameron. “That immediately puts ‘non-Superusers’ into a defensive mode.” He asks, “If clicking a few buttons puts you out of a job, should you be doing that job in the first place?”
Figure 4.2
Social virtual reality at CannonDesign TiP. (2018) Credit: Laura Peters.
AI: augmented and informed vs. being fully automated
Woods Bagot is engaged in a project to look through their standard delivery processes to think about how much they can automate. “That’s a pretty big conversation,” says Shane Burger. “We’re basically going step by step, saying Project A needs to put together a PDF set and upload it into this system and end up with these people.” Burger continues:
We’re trying to go through this process where we simplify and further develop a lot of our delivery management processes that we use in the practice. What we started discussing was UK delivery standards vs. other regions, to take what I would argue was a 1980s or 1990s method of management and update the whole system. The second step of that is to start looking through those gaps in process. Those things that are very repeatable tasks that we do all the time, and start to look for easier ways to automate them.
But what specifically is meant by automating processes? One example that’s on the more opportunistic side is where Woods Bagot, which has a very large interiors practice, is starting to think about stronger connection points between their Revit libraries and how they manage their libraries of content, the method with which they develop their cut sheets and track their use of products across the company, and right now, what is a manual generation in Microsoft Word or InDesign of that delivery package to the client. Burger explains:
These are things that we do again and again and again. And we might as well automate that. We did another one that is a basic urban site study step. It was 20 pages of content that would typically take somebody 2–3 days to do in Illustrator and AutoCAD. We basically automated that process and turned it into a 20-minute step. Andrew Heumann worked with me on that one. We spent 4–5 days and built this thing up to automate something that we do at the beginning of every single project in New York City. It just comes up all the time, so we always produce this content. I wouldn’t call this AI so much. It’s just pure mechanization. We’re just trying to automate a lot of these steps that are in there.
I don’t have a firm position on where we, as individual humans and designers, are going to provide a greater level of expertise than what we can get out of an AI. I am of the opinion that we underestimate what the AI will be capable of doing in the long term. This goes back to Amara’s Law [We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run]. Everybody’s going to be talking about AI designing stuff for us in five to ten years. No, but there’s a pretty good shot that it will hit it in 20 years or more. And more so than we think it is going to. We’re going to be pretty surprised at the kind of stuff that’s going to be there. It’s simply going to be a question of where we think human judgment is going to provide a unique value over somewhere else. We shouldn’t be the people doing code reviews or any of that stuff that is documented as a process in a manual somewhere and you simply have to go through the steps to do it. You should effectively then have an augmented interface that’s provided to you that gives you warnings, notifications, or a solution space to work within that always satisfies the conditions that are necessary. But then you have to take the judgment that says, OK, when it deals with prioritization of those factors in the solution space, I am going to play around with it and say this is more important or this is more important. Safety and such will always trump everything else. But at least it puts you in a position where all those automated checks that we typically have to go through on projects, there’s no reason any of us should be doing this stuff. I would be perfectly happy for that stuff to go away.
Burger describes an augmented and informed approach to design that is not automated:
What I am starting to think about is a ubiquitous heads-up display for design. That might even be something like – we’ve talked about it with our workplace sectors at Woods Bagot, whether interiors, lifestyle, or residential – a display that might be specific to the typology or sector that you’re going after that provides you with information to keep you up to date as you’re working through the design.
That was even part of the approach with the user interface work that I was doing with Brian Ringley and Andrew Heumann. It’s not always something that you want to input into, but that you want to receive feedback on while you’re working through the process. This augmented and informed approach is going to be increasingly important for any of those things that are not going to be fully automated.
Do we need to fear that by automating what we do, design professionals will eventually lose their jobs? Repeatable automatable tasks that are broken down into their constituent parts are referred to as deskilling. The word implies, especially with machine learning, that the algorithms will pretty much do what we’re currently doing, and in the long run, in perhaps 20 or 30 years, it’ll put us out of at least that job. “In the AEC industry, it is a bit harder for automation to completely take the role of an architect or the engineer,” says Hiram Rodriguez. He continues:
However, we may have tasks within these roles that will benefit from a complete automation, allowing us to focus on other things. The AEC industry has too many problems to solve right now. One of them is the data is not the same in some of the industries, so we need to come up with ways to create standards that will help all industries moving forward.
User experience
Ease of use, accessibility, reduction of pain points – these are all examples of an improved user experience, value-added that’s the result of working with a Superuser. According to Rodriguez:
In terms of accessibility, some people don’t realize this, but visual programming tools, like Grasshopper and Dynamo, were invented because we’re more visual in the design field or architecture and structures that we need to visualize something … But then even then, some people just look at that and see it as spaghetti. Then you come up with plug-ins like Human UI that make visual programming tools easier to use.
Do design technologists see making tools useful for everyone as a form of user interface (UI/UX)? Do computational designers need to have the ability to lift the hood on tools right out of the box to customize them to make them user-friendly? “Yes and yes,” says NBBJ Design Computation Leader, Dan Anthony:
The idea is that we do complex things for a clear reason. We’re increasingly calculating more difficult problems and solving more complicated design challenges. But we’re doing it for some kind of clear goals. Especially when you think about something like machine learning coming into the field in the form of design augmentation, it’s only going to be useful if a designer or someone in another role who is working on a project is able to understand the intent or purpose, how to apply it, and how to cycle through it. It’s all about user experience. In the near term, it’s hard to see how we’re going to put things in human’s hands that are going to be easy to work with. Things like the voice-activated tools (e.g. Google’s home tools or Amazon Echo’s Alexa, that are able to easily transmit complicated knowledge to people) with really nice mobile design, hint at intuitive processes but also can communicate complex ideas …
But at the same time, one of the best things that has been happening, and one of the things we should strive for, is that when you find that the basic problem isn’t solved by that clear interface [here we go back to the title of the book] your regular user is going to need a slick interface that helps them understand things. The Superuser is the person who knows that you can lift the hood. And that when you do lift the hood, say to an Autodesk product, that there is a clear API, that’s still easy to navigate, and lets you connect/reconnect items. That’s why visual programming has been so successful. It has made Superuser status a little more attainable. These are very complementary positions to be in. Because there are times when I don’t want to be writing the API interfaces. I want to at a certain point land at a tool that’s going to be useful.
Google Cardboard, to use IrisVR’s Ana Garcia Puyol’s phrase, is a down and dirty, cheap technology. It’s ten bucks! What role does an entry level tool like that play in inspiring experimentation and messing with tools? Garcia Puyol admits:
If you had given me a $30,000 piece of equipment, I wouldn’t have dared to dream. I would have thought, “yeah, this is so cool, this is the future, but not the present.” For me, that particular evening, I thought, “This is it, this is what I’m going to make my immediate future about.” It was what I could get to work on and it was accessible. It’s funny because now I don’t do any work with the Google Cardboard and it’s more something very entry-level, a backdoor tool for many people. I went to TT and created a proof of concept over the weekend relying on affordable technology. That couldn’t have happened with a very expensive piece of technology. What would have been the point to build something for users that doesn’t exist yet, for users who cannot afford it? Because, even now, we still struggle with it. If VR takes off, it’s still expensive. But if VR had been a piece of technology that’s very, very expensive, then why would you invest in that? It makes me think of Tesla and SpaceX and how some people just really bet on very expensive technologies with the goal of making them cheaper eventually and that’s great. But on my end, I wasn’t building hardware. I was building software. For the success of my initial idea and even what we do here: you’re building on top of a technology or a piece of hardware that has to be accessible for people. Otherwise, you’re doomed.
“My YouTube web series has taught me that this culture isn’t for everyone, but that doesn’t mean only certain people can use high technology,” says Ryan Cameron. He continues:
The key is making it accessible, easy to use and, if you’re really good, make it fun. Most people don’t need to understand what’s under the hood, they just want to learn to drive. I do believe that design professionals need a basic understanding of what data means to them if they are to succeed.
Figure 4.3
Konstru BIM interoperability platform. (2018) Credit: Thornton Tomasetti CORE Studio.
Interoperability: connecting communications, processes, and people
As already mentioned, Brian Ringley and Andrew Heumann worked on Wombat when they worked at Woods Bagot. “That stuff is fun and valuable and it’s fun to promote, but you go to RTC or BILT, and AU, and it gets a little tiresome,” says Brian Ringley, now with WeWork. He continues:
It might also just be where I’m at. I’ve gone through various phases of interest and I actually think it was really interesting timing for Flux to drop that product. But I also felt like they had ushered in the era of interoperability.
I am interested with the history of what’s going on with just the idea of open data. I do feel like they helped popularize and usher in an era of JSON web plug-ins for exchanging data, and then people are like, “Okay, I can do that, too, or I can make my own sauce.” Do I think that is what is actually the biggest crisis facing the architectural business model? No. That’s why Flux didn’t make enough money. It’s hard looking back, because as somebody who was very close with them early on and very excited about the tools, it was like, “Well, of course I was excited, it made my life so much easier,” and it made a meaningful impact on the way we deliver buildings. Bjarke Ingels’ The Eleventh project is rising out of the ground right now, and that was absolutely made easier through the use of Flux. Could we have done The Eleventh project without it? Sure. It would have been a lot more painful. It’s hard because you see the immediate value as somebody who has the expertise, and especially somebody who’s working with complex geometry versus more standardized architecture, but ultimately when you see it go, you’re not surprised. It’s hard to beg a firm to pay that much money for it because that’s not the biggest problem facing firms … It was never connecting the tools. It was connecting communications and connecting processes. Maybe it’s just because there have always been manifold solutions to it. It wasn’t like, “Oh, my God! How do I go back and forth between Rhino and Revit?” It was “How do I work with all of my consultants? How do I manage all of that data to meet deadlines?” That’s not tools.
Figure 4.4
Announcement for the public release of Wombat, the design computation software authored by Andrew Heumann and Brian Ringley at Woods Bagot. (2018) Credit: Woods Bagot.
Seeking new technologies: software development and tool creation
The best architects and engineers build their own tools – that’s the design profession’s new reality. “With the proliferation of Grasshopper and now Dynamo, we now can build almost any tool to do anything we want. The more experience we get with that, the more powerful that will become,” says Stephen Van Dyck. “For the most complicated problems, our tool is crafted by us. I believe that when we can design our tools, we get much better outcomes.” If not creating their own tools, do Superusers proactively seek out new technologies – or do so reactively, by waiting for others to bring them to their attention? “There is definitely a proactive element,” says Dan Anthony:
One thing that I personally feel deficient in is that I don’t always stay socially active e.g. on Twitter. Part of it is that I sometimes have a hard time getting through the chaff of it – there is a lot of noise in that space. But I do think following asocial media is important – I do track it. Research is another very important part of this. And I do a lot of research. It’s about leaving space to explore what’s available. It’s part of my job to do this. It’s not time that I have on the books. But something I think is critical to succeed at my job. A lot of times we have these clear goals where we really want to figure out a way for doing something. The risk for us is that we start down a path where we’re trying to reinvent the wheel. I grew up with the Internet as a way of solving that problem by searching for that information. Reaching out to people, asking them questions, is a great way to solve that problem. The key is that you do a really thorough job of exploring what the state of affairs is, by digging through GitHub, by reading journals to see if anyone has tried to solve this before. Sometimes they don’t want you to know that they’ve tried to solve this problem.
And when technologies cannot be found, Superusers create them. KieranTimberlake is a firm that not only leverages the latest technology but creates its own tools. As partner Matthew Krissel explains:
It is important to note that making a digital tool can be a simple script that may only take an hour to make, and people make them on their own all the time. Other tools might require a few days or even years. So, our process calls for an objective assessment of multiple possible outcomes. It is important that we first look for existing tools as we are not interested in making things just because we can. We test multiple tools before we start to invest in making one. When we are testing tools to purchase or that we made you always do it on real projects, with real teams and deadlines in order get the kind of assessment that is useful.
In all cases, one answers a series of questions, like: What is the need? Do we already own something similar? What will this allow us to do that we cannot do now? Have you tested it? What is the workflow? What agency will it provide? Is this hardware, standalone software or a plug-in? Is this on premise or cloud hosted? What are the costs? Purchase or subscription? Is this project specific or firm wide applicability? This is then evaluated by a small group of the firm’s decision-makers and they determine that if it exists, they may green light the purchase or do an extended demo on a real project. If one does not exist, we do a deeper analysis to determine if we should build it.
This involves setting goals and defining the objectives and what problem it would solve, market research and gap analysis within and outside our industry. If positive, we then build a proof of concept and conduct an assessment and feasibility review, asking: Is it desirable? Anybody want it? Is it feasible? Is it viable? Can it be done? If we proceed, then it’s into further design, refinement, build partnerships, gather feedback.
It is also worth noting that the need for tools arises in many ways. Sometimes we identify needs through conversations within our Digital Design platform. We have created five task teams that cut across and touch just about everything in our practice to drive the computational discourse. 1) knowledge acquisition, 2) knowledge management, 3) BIM practices 4) visualization practices, 5) near future practices. Each task team meets weekly or biweekly, building discourse around these areas of practice, so all kinds of needs bubble up. The task team leaders help prioritize, coordinate, and make resources available to address them. Needs are also identified in the Tools and Workflow sessions. And sometimes, a need or idea simply comes up during the flow of design on a project.
Figure 4.5
Superusers want to be on top of emerging technologies. (2018) Credit: Deutsch Insights.
Commercialization of tools
In recent years it has become popular to say that every firm needs to be a software firm. More critical, perhaps, is the importance of elevating everyone’s digital IQ. Krissel says:
The comfort with and ability to make tools is important, but that does not mean EVERY firm needs to become a software firm. Unfortunately, there are people leading firms who have no idea what tools people are using. No idea why they use one over the other. Every person up and down the firm may not necessarily be using the full kit every day, but there are many ways that everyone’s digital IQ should be elevated in the industry …
Regardless if people are authoring content, modeling geometry, or running a simulation or none of the above, I think it is important that the people in a practice know the what and why, otherwise they will never really be able to get behind the work. Once you elevate everyone’s digital IQ, you start making lots of little and large improvements. Not necessarily to always commercialize, but to improve the day to day, and increase opportunities and expectations for the people around you and the projects.
The commercialization of tools does create an opportunity area for firms. “Yes, there is lots of room here for firms large and small as there is no shortage in sight for improving how we work together and understand the work,” says Krissel. He continues:
Commercializing software is not easy and becoming too obsessed with it in an architecture practice can create some unfortunate motivations that can detract from one’s capacity to do great projects. You must go back to those first principles of why you are practicing architecture. If it’s about making tools only, then perhaps you should become a software company. If it’s about making great architecture, and you happen to make tools when the project demands it, you’re an architect who can make tools. Designers making software and hardware as well as designing buildings should not be mutually exclusive endeavors, rather they reflect our time in history and our path forward. These business sectors will continue to blur. The real question is, what are you in this for? Answer this and the rest takes care of itself.