I was at IBM’s INDEX Developer Conference earlier this year and it was a nice change to be surrounded by code—and how to think about code. Before I was an Agile Coach, I was a software developer, so this was a way to return to my roots. I thought the most compelling talk at the conference was given by Sarah Mei; she introduced a delightful new paradigm for conceptualizing a code base that encouraged us to think of it as a living space, like the interior design of a house.
Software Design is not Architecture
Sarah eased us into her concept by reviewing established approaches to thinking about the work of designing and building software. One of the most pervasive of these is the idea of software as “architecture.” We build complex, interconnected applications. Many of the terms we use are borrowed directly from building structures. We talk about “wiring up” components and our application’s “plumbing.” These analogies are readily accessible and make sense, but they’re also flawed.
The idea of “software as architecture” reinforces the assumption that if we invest enough time in our design up front, then we can create plans that, like blueprints, reduce risk and minimize changes. That may be true with a real building, but it is demonstrably false in software. That’s one reason Agile approaches—and the idea of emergent design—have become so influential. We learn as we go, so we cannot design it all up front. I believe we shouldn’t use analogies that reinforce the idea that we can; instead, we need something new.
Software Design as Interior Design
Sarah offered an alternative. She noted that with the introduction of powerful new frameworks—like Angular and React for JavaScript—much of the repetitive work that used to be commonplace is no longer necessary. Instead, developers create and arrange core building blocks in clever ways to create new applications. Those building blocks, and the code within them, can be thought of like the rooms in a house. We determine their relationship to each other, and we choose what we store in each one. These choices are important; they’re also highly contextual.
This is what I think makes Sarah’s concept really clever. Living spaces are a unique reflection of the people who occupy them, and my house—with my wife and two children—is arranged very differently from my mother’s. We would expect no less, given where we are in our lives and our different needs and interests (while she has a basement shop for woodworking, I have one full of kid’s toys). We can look at code the same way; the arrangement of the code should reflect the needs and interests of the team that works on it. Those needs will differ. A team of three very experienced engineers will occupy a very different “living space” than one inhabited by a team composed of one senior lead and four more junior developers. Rather than expecting teams to conform to the same “best practices,” we should allow them to adapt their space to work for them and facilitate their growth and learning.
Living Spaces are Lived In
Sarah used the importance of context as a departure point. She expanded on her analogy to explore two unfortunate extremes. The first was the incomprehensibly messy code base—the fragile ball of spaghetti that nobody wants to touch—and the second was the sterile design that looks beautiful, but is impossible to live in.
Spaghetti code is like the house of a hoarder. It’s confusing to navigate; it’s difficult to find things; and it’s hard to make effective changes. Sarah believes her analogy can be helpful by reminding teams that their code is where they live. Every decision they make is an opportunity; they can either help keep their space clean and easy to navigate, or they can make it more confusing. The choice is up to them.
Sterile designs—at least for interior decorating—abound. We see them in magazines and on TV shows, like “House Hunters” and “Divine Design.” Staging techniques are intended to welcome us in and make us want to buy. Sarah drew an analogy between these approaches and the software “best practices” we regularly hear about in blogs and presentations; they also sound very appealing… but whether in code or in real life, none of these sterile approaches lead to a space that is “livable.” Livable code, like a livable house, is occupied by real people, and those people will have real needs. The beautiful designs have to be brought to reality—they have to become lived in—before they can be useful. The art of good software design involves figuring out how best to contextualize them—how to make them living spaces—for you and your team.
I think Sarah’s analogy is very useful; it shatters established paradigms and introduces a new mental model that more effectively represents how we work today. I’m looking forward to using it to help teams better conceptualize their code and how they live in—and with—their design choices.