Building software products like building physical spaces

4 years ago, right around the end of the 1st year of graduate school, I made a conscious career decision: to transition from architecture to building science and software engineering.

Over the course of these 4 years, I have been involved in all stages of the software development process, from hacking together one-off scripts to process data, to helping stand-up distributed compute infrastructure, to designing and implementing data warehousing systems, APIs, and web applications. It wouldn’t have been possible without the mentorship and guidance of Jeremy Lucas and Sam Steyer who I have the pleasure to work with every day at Station A.

As an architect-turned-software engineer, I sometimes ask myself: ‘What are the lessons I learned in architecture school that would be translatable to my career in software?’. When I think of building a software product as a process, it shares a remarkable number of similarities with the process of designing physical space.

Here are some principles I have found to be consistent in both the architectural and the software development process.

Understand the user

Architecture requires deep understanding of the user: you wouldn’t be able to design a house for an occupant (real or hypothetical) you know nothing about. You would have to start by comprehending their needs, habits, culture, and aspirations to be in a position to develop a design. Similarly, a good software product needs to be able to address the needs of its users. The day of a product manager is filled with user testing, interviews, and storyboarding for good reason: to ensure that the product makes the user’s life easier by addressing a real need.

One of the things I have really come to appreciate about the software process is the speed of deployment, testing, and iteration. At Station A, we can put a new product in front of users in a matter of seconds, get them to use it, solicit their feedback and improve upon it. The equivalent process in architecture is much slower, expensive and limited: physical models, 3D renderings and VR walkthroughs go a long way but don’t come close to the real experience of a built space.

Understand the context

As you can probably tell by my research interests, I am a big fan of architectural design within context: considering the environmental conditions, cultural fabric, and existing building stock surrounding your design. This doesn’t imply that architecture has to be reactive, but rather that it should seek to enrich and amplify its context rather than overshadow or -at the other extreme- be defined by it.

Software products are interesting in that regard: you don’t want your application to just complement an existing process, but to encourage users to think about the status quo more creatively, and even slightly upend it. The only way to do this as a product manager is to know your product’s context: competitive products, market trends, and emerging technologies worth looking into.

Design for maximum flexibility

Architecture has to be able to adapt to an occupant’s ever-evolving needs and way of life. For this reason, an architect needs to design for maximum flexibility, anticipating changing conditions -a couple of examples:

• Flexibile space utilization: Folding furniture and open floor plans with no fixed partitions to allow easy indoor layout reconfigurations
• Flexible shading: Dynamic shading systems or glazing materials that react to the amount of sunlight they receive to optimize indoor conditions
• Flexible facades: Facades that react to environmental conditions or occupant preferences to alter the performance or appearance of a building

Software is very similar: not only does it need to be able to anticipate shifting user needs, but also be designed in a way that allows easy future additions and enhancements. At Station A, we embrace flexibility in two ways:

• Flexible system design: Building back-end data systems that allow us to ingest and process new datasets fluidly, without the need for customization
• Flexible product design: Designing our product in a way that allows us to easily add new features, expose enhanced data, and iteratively improve on user experience

Leave room for experimentation

Experimentation is a prerequisite to innovation. Testing a new idea when developing a building design can lead to unexpected revelations. That could be anything from a new way to arrange a floor plan, to a new facade material, to a new natural ventilation or daylighting strategy. In a lot of ways, out-of-the-box thinking is expected of architects, and when it’s succesful it can really transform the occupant’s experience of a space.

In the world of software, experimentation is cheaper and requires less effort. From testing out a new software technology, to deploying a new beta feature for a select group of users, trying out new things and soliciting feedback is fast. Experimentation lends itself well to the iterative nature of the software development process, yet it has to be done in a way that inspires rather than alienates users.

-M