00:00:18.230
I'm told that you're supposed to begin every talk by introducing yourself and establishing your credibility and expertise. However, I think that's more relevant for the Java crowd, who need to know that you have advanced degrees in architecture and astronautics. We're still a young community, and hopefully, this talk will stand or fall on its own merits. But for those of you interested, I'm from Toronto. You know the rule: the further the speaker travels, the more you listen to them. Personally, I think that rule is evaporating in the age of the internet, but I'm going to milk it for as long as I can. I'm here to share some of my experiences and opinions about design and communication.
00:00:40.890
My talk violates some of what I'm going to tell you in that it somewhat rambles around a central theme and eventually circles back to it. The underlying message is that good design obviously involves thinking about the user, and we developers are users as well. We are the users of our software architecture and design—not just in terms of user experience, but in how we organize and write it. Many people compare software architecture to building architecture, and some have written long essays arguing that there aren't nearly as many parallels between the two as people would like to think. However, that doesn't mean we can't learn things from building architecture.
00:01:10.650
Today, I'm going to share some insights I've gained from a particular architect, a woman who wrote a book called 'The Not-So-Big House.' This book has a fascinating concept. We often talk about unobtrusive design, and the title itself speaks volumes about the principles it covers. This is my first talk of 2013, and I can guarantee that every single talk following this will improve on it.
00:01:28.920
Sarah Susanka is the architect in question. Has anyone heard of her? Clearly, she needs to get out more. She authored the best-selling book 'The Not-So-Big House,' which eventually grew into a series, including titles like 'Chicken Soup for the Soul' and 'The Not-So-Big Life.' The original 'Not-So-Big House' is amazing, along with its remodeling counterpart. Her philosophy is quite insightful and serves as a strong preamble to my discussion on software design.
00:02:19.630
All design starts with a problem that needs to be solved; without a problem, there is no design. People often complain about clients, bosses, or users, saying 'blah blah blah, problem, problem, problem.' The reality is that without problems, this room empties. The problem Susanka aims to address with her philosophy revolves around single-family dwellings. She focuses on what is unique to each homeowner rather than what all homeowners have in common. This perspective resonates with me as an underlying philosophy of software design.
00:02:42.210
The most important aspect is identifying what is different about each application, rather than what they share. Our industry often emphasizes commonalities, with entire conferences devoted to frameworks like Ember or Ruby. If I had a magic wand, I might reorganize how we conduct conferences. It could be valuable to focus on specific domains, like banking software, and have discussions with those who work within them rather than discussing common implementations across frameworks.
00:03:23.640
Susanka believes, like many others, that form follows functionality. In design, when you look at a well-thought-out house, it should be obvious what kind of people live there and what their lifestyle is like. In contrast, many model homes resemble sterile environments where you couldn't possibly discern the homeowner's identity. Inexperience often leads buyers to mimic designs from magazines, resulting in houses that feel the same, regardless of who lives there.
00:03:50.280
Our homes should reflect who we are. A home is not merely decoration; it’s a functional piece of equipment. For example, given a customer's budget, which might be for a 4,000-square-foot house—considered a good size in America—she often proposes designing a 2,400-square-foot home that provides more value. The challenge is in ensuring that this smaller house meets the design needs in a way that is more beneficial than a larger house. I've spent years trying to convince customers to pay the same for fewer hours of development, although I haven’t been as successful as she has.
00:04:31.140
What most people end up buying in America is a 3,500 to 4,000-square-foot house. Builders market these homes by emphasizing elevation and design features, presenting them on paper in an appealing way, but at their core, they remain boxes. This approach maximizes square footage for minimum cost, prioritizing price per square foot. Consequently, new houses are mass-produced with limited customization. Builders don’t need to know the lifestyle of a homeowner or the specific needs of individual clients because the business model supports a generic approach.
00:05:32.550
But what problems do these big houses solve? They convert a generic structure into a product for sale. The whole process is designed to cater to buyers who are often uncertain or inexperienced about what makes one house more valuable than another. This lack of experience can lead people toward superficial measurements rather than insightful value assessments. Similarly, managers often prioritize visible metrics over subtle, more meaningful attributes, which can lead to superficial business decisions.
00:06:29.960
Most home buyers are unsure of what they want or if what they choose is the best fit for them. This uncertainty breeds fear, leading them to cling to the more obvious and simple housing choices. You can see this trend in many large corporations where fearful employees prefer established norms and clichés. Selling a house based on square footage is the obvious route—quick and clear-cut. Digging, however, reveals significant insights on houses and how we sell them, mirroring our industry in many ways.
00:07:41.430
In our industry, if a decision-maker is inexperienced, they will rely on simple and measurable pieces of information instead of more subjective, complex insights. These metrics often lack the depth of evaluation that truly represents value. Designing with maintenance in mind involves recognizing this distinction—if we ignore the subtleties and ignore the direct implications for the less experienced users, we risk losing out on vital insight. Just as people don't want to live in cavernous spaces, software design should reflect comfort and clarity rather than merely highlighting size and footprint.
00:09:36.170
As I wrap my preamble, let's transition to software design and explore principles from what Susanka offers for house design. I've borrowed her title, 'The Not-So-Big Software Design,' to express the same ethos. When discussing small to medium business applications, the emphasis should be on what's unique about each application rather than what's common across all applications.
00:10:01.920
Not everyone needs to start big or how every application could model a particular structure. The concern should be about how to best serve the actual problem the user is facing. Too often, we articulate commonalities in terms of frameworks, but they fail to capture the nuances that make each domain distinct. We must shift our focus from what framework fits best to what each application truly needs.
00:10:48.920
In the same way that in housing design, form follows function; software design should prioritize the domain’s needs first. Currently, the prevailing notion of value in frameworks and libraries often boils down to how well can these tools store and organize our data. Initially, they serve a purpose, but as we gain familiarity and depth in our usage, we should question their relevance and our continued reliance on their structures. A common response is to ask why we would remain tied to conventional arrangements when there are better, more efficient ways to organize our code.
00:12:18.990
The distinction between a library and a framework is crucial: A library provides tools to build a custom solution, while a framework offers a predetermined structure wherein developers must fit their specific needs. The big frameworks simplify the initial onboarding for new developers. While this is a necessity, reliance on conventional frameworks often breeds a mindset that every project is merely a variation of another, thereby diluting the distinct needs of clients and their projects. This becomes so nuanced that developers start viewing code organization merely as a means of convenience rather than ensuring it meets the specific project requirements.
00:13:41.600
As a designer and as a programmer, it is essential to remember that our solutions must align tightly with the value being generated by the specific application. Finding that right design balance leads to communication that goes beyond mere algorithms and structures. Emphasizing what's frequent and essential about how a particular application uses its components can create far more maintainable systems over time. When we rely too heavily on conventional wisdom without questioning its applicability to our unique situations, we run the risk of creating something that has less intrinsic value.
00:15:04.000
In summary, as we strive to create more effective systems, we must focus on the end users and their unique needs. By highlighting frequent and relevant usage data when organizing code and by holding onto key knowledge, we can ensure that our future projects remain responsive to user needs rather than rigidly fixed in common frameworks. This approach argues against adherence to one-size-fits-all methods in favor of tailored experiences, exploring how flexibility can lead to better outputs in software design.
00:16:21.000
The takeaway here is to adopt a mindset where we recognize each project's uniqueness. Utilizing modular components can help us compartmentalize our features without losing flexibility or communication between critical functions. This practice upholds both clarity and cohesion in function and organization. Software, much like homes, is layered and intricately designed, and we should treat each layer with the specificity it deserves.
00:17:17.600
If we were to visualize these concepts, we would see elements organized in a way that reflects their purpose rather than simply presenting them by type. The current design paradigms being followed might favor organization by file types, which is less significant than understanding how the components communicate and what their roles are in the broader application context. It's essential to communicate the roles and purposes clearly so every end user sees the value embedded in the architecture.
00:18:11.720
By framing our discussions around the underlying use cases instead of confining our thinking within existing constraints, we progress toward better architectures. Software is not just about lines of code; it addresses problems with effective solutions and considerations. When we utilize design patterns tailored to unique projects, we build systems that are both enduring and relevant, providing real-world applications that demonstrate tangible benefit to the users.
00:19:02.360
So as I finish my discussion, it’s essential to appreciate that our interactions with software design demand a user-friendly approach, ensuring accessibility and clarity. Building to spec often sacrifices the subtleties that come with a deeper understanding of users’ needs—profound insights that enter the design discussion create values that outlast the features being implemented initially.
00:20:01.400
It's about creating an enduring dialogue with the users as they engage with their applications. Crafting an architecturally sound solution is akin to aiming for perfect home design where every aspect matters. Presenting an integrated approach—where both form and function complement each very necessitates embracing a cognizant consideration of how each house or piece of software works.
00:21:17.400
Just as you’re unlikely to run a plumbing job without thinking through the connections within varied elements of house design, we should approach software in the same manner. The design should reflect clarity, and toward that end, working within systems like frameworks need to be approached with flexibility, allowing room for change once initial decisions are made—adapting without losing sight of user necessity.
00:22:47.000
The practical application of these ideas allows for user-focused design that resonates with real-world requirements rather than vague forms. The key is adopting systems with a mindset that prioritizes individual user interactions, shaping a framework of engages users deeply with substantive results for each solution implemented. Aim to create solutions that speak not only to the construct itself but invite user involvement into the equation.
00:23:52.800
In software design, it’s critical to embody clarity and dynamic organization by keeping the core values at the forefront. This means building a system or home that remains flexible without getting trapped in rigid structures. So, as we finish these discussions today, take with you the idea that while solutions may evolve, the emphasis on user-centric design must endure. You are responsible for creating experiences that pay respect to the essence of real problems.
00:25:31.900
By pursuing this path—recognizing the user, prioritizing clarity, and motivating flexibility—your design will capture the spirit of true innovation. While structures may stand as the foundation of construction, your practices in software should reflect the intricacies of design and remind us that ultimately, it’s about human experiences. Appreciate that every element—be it in a home or a software system—deserves due diligence to fulfill its role sustainably.
00:27:22.040
You're not merely building a product but establishing an experience for the user that remains functional, relatable, and meaningful. Thank you for your time today and for engaging with these thoughts on how we can approach design—both software and homes—with a more critical perspective aimed towards improvement and understanding of unique needs that contribute to success.
