Presenters

Source

Unlocking Software Design: More Than Just Code – It’s a Conversation! 🚀💡

Ever felt like “software design” is this elusive, shape-shifting concept that everyone talks about but no one quite defines the same way? You’re not alone! In a recent GoTo podcast panel, industry luminaries Sam Newman, Jacqui Read, and Simon Rohrer dove deep into the heart of software design, its intricate dance with architecture, and how we can make it a more collaborative, effective, and less-overlooked part of our daily work. Prepare to rethink how you approach building software!

🧐 What is Software Design Anyway?

When we hear “design,” many of us instantly picture user interfaces or code structure. But Jacqui Read, author of “Communication Patterns” and founder of the Ministry of Software Design, challenges this narrow view. She argues that design permeates every layer of software development.

“If I asked everyone in this room what software design is, I bet I would get like a hundred different actual definitions,” Jacqui states, highlighting the common confusion. She emphasizes that design isn’t just about the top bit (UX/UI) or the bottom bit (code layout), but about the entire flow from context to end result. From understanding user needs to architectural decisions and even engineering implementation, design is an ongoing process.

Simon Rohrer, Head of Enterprise Architecture at Saxo Bank, echoes this, speaking about “self-similarity and fractals at different scales” and how design happens on different time frames. Whether it’s an in-the-moment decision or a long-term strategic choice, design is constant.

But here’s the kicker: design is often the first thing to get squeezed when deadlines loom. “Oh, but we need to get this out by the end of the week. So, we just forget that bit. We just code. It’s fine,” Jacqui quips, perfectly encapsulating a common industry pitfall.

Design: A Series of Intentional Choices ✨

Is design a set of decisions, or are these choices forced upon us? The panel clarifies that design is about making choices, but crucially, it’s about understanding what people need. It’s not just about a technical decision like “we’re going to use Kubernetes,” but about gathering input from all stakeholders – end customers, business needs, and even legal regulations.

Jacqui champions the idea of “decision records” for everything, not just architecture. She believes that business decisions, strategy, hiring, and finance also deserve to be documented with the same rigor as architectural choices.

✍️ The Power of Decision Records: Beyond Architecture!

Architecture Decision Records (ADRs) are a powerful tool, but how many teams genuinely use them regularly? Sam’s informal poll showed only about a quarter of the audience did. Simon noted that Saxo Bank, with its 3,000 employees and 800-900 developers, is increasingly adopting them, starting with company-wide decisions and encouraging their use within domains and teams.

Why ADRs are Your Best Friend 🤝

  • Recording the “Why”: The primary purpose of an ADR is to document why a decision was made, along with its context, inputs, and considered options. This prevents the dreaded “whack-a-mole decision” where questions resurface repeatedly, wasting time.
  • Onboarding Aid: ADRs are invaluable for new team members, providing a guided tour through crucial past decisions.
  • Permission to Change: By documenting the rationale, ADRs allow teams to revisit decisions. If the context has changed, you have a clear path to supersede it with a new, relevant choice.
  • Fostering Dialogue: Simon emphasizes that ADRs are a process, not a decree. They facilitate conversations, getting stakeholders involved, and considering options. The goal is to cut off (the etymology of “decide”) less favorable options, but only after a thorough dialogue.

Making ADRs Stick: Practical Tips 🎯

A common challenge is making ADRs the “source of truth.” Here’s how to overcome it:

  • Meet People Where They Are: Don’t force new workflows. If your team uses Notion, Confluence, or even SharePoint (poor you, Jacqui jokes!), put the ADRs there. “Put it where people who need it will use it,” Jacqui advises.
  • Over-Communicate: Simon highlights the need for continuous repetition. “You can’t just tell people once; you’ve got to tell them time and time again. You’ve got to use channel after channel after channel.”
  • Information Radiators: Replicate the visibility of old-school physical whiteboards in a remote world. Pinned messages in Slack or Teams, or mentioning ADRs in regular showcase and retrospective meetings, can keep them top-of-mind.
  • “Front Door” Access: Create a high-level entry point to all decisions, allowing people to find what’s relevant to their project or domain.
  • Put the Answer First: As Sam and Jacqui suggest, name the ADR with the decision itself and structure it like a newspaper article: headline first, then details. Some people just want the answer!
  • Draft Status: When sharing initial architectural ideas, label them as “draft” or “proposed” to encourage contributions and avoid making engineers feel decisions are already set in stone. Jacqui even suggests using “sketchy” visual formats to convey tentativeness.

🌉 Navigating the Architect-Engineer Divide

A crucial point raised by an audience member was the tension between architects presenting a high-level “minimal viable skeleton” and engineers perceiving it as a rigid, unchangeable decision.

  • Collaboration is Key: Architects should act as facilitators of conversations, not dictators. They need to listen and be open to feedback, even reading body language.
  • Start Fresh (Even with Legacy): Jacqui suggests that even with legacy systems, it can be better to start with a blank slate, fostering collaboration to discover what stakeholders really want, rather than assuming the existing system meets their needs.
  • Accountability vs. Creation: Architects are accountable for the architecture, but how they create it matters. Co-creation is the ideal model.
  • Habitability: Sam introduces the concept of “habitability” – architects create the environment developers will live in for months. A decision can make a developer’s life miserable, so involving them is essential. “You are creating an environment in which your developers are going to be living for a period of time, so I think you do have to do it together.”

From Engineer to Architect: Bridging the Detail Gap 🧑‍💻➡️🏛️

An engineer transitioning to an architect role asked how to balance the developer’s need for low-level detail with the architect’s high-level view.

  • Focus on Outcomes: Jacqui advises architects to communicate outcomes rather than dictating precise implementation. Architects “know a little about a lot,” while developers have deep, specific expertise.
  • Empower Teams: Architects should make decisions relevant to their level (e.g., standardizing across teams) and then empower teams with the right knowledge to make specific implementation decisions.
  • Last Responsible Moment: Delaying decisions until you have enough information is crucial, but acknowledge you’ll never have all the information. Build for change!

🚀 Scaling Design & Communication in Large Orgs

How do you communicate design decisions effectively to 800+ developers?

  • Continuous Repetition: As Pat Kua once said, “For software design, don’t repeat yourself is important; for communication, cry continually repeat yourself.”
  • “Hear It Back”: You’ve communicated enough when someone you’ve never met is telling you what’s supposed to be happening, without realizing you were the original source.
  • Vertical Slices & ACE Model: Jacqui and her husband’s ACE model (acemodel.com) visualizes design from context down to engineering in “vertical slices,” allowing you to do “enough design to move on to the architecture and enough architecture to move on to the engineering,” avoiding waterfall pitfalls.
  • Fractal Approach: Simon describes Saxo’s approach as a “fractal interlink” between organizational, technical, and value architecture. It’s about knowing “who knows people who know people” to ensure information cascades correctly.

Standardizing vs. Over-Standardizing ⚖️

When should you standardize design choices across an enterprise?

  • Don’t Over-Standardize: Simon cautions against removing needless creativity. Developers should be creative in the business problem space, not necessarily in choosing every OM tool or serialization library.
  • Platform Engineering: Gregor Hop’s (and Desmond Duza’s) concept of platform engineering is where “the architecture lives.” It removes “needless creativity from developers” by providing standardized platforms.
  • Cost of Change: Sam highlights a critical tradeoff: standardizing increases the cost of changing your mind later. Only standardize where the long-term benefit outweighs this future cost. If a decision has a low cost of change, don’t sweat it!

🚧 Tackling Common Design Traps: Over-engineering & Outdated Docs

Audience questions revealed common pain points: meetings spiraling into detail, over-engineering, and documentation falling out of sync with code.

  • Avoid Rabbit Holes:
    • Breakout Groups: If a discussion gets too detailed, Sam suggests forming small, cross-functional subgroups to break out, tackle the detail, and report back.
    • “Parking Lot”: Jacqui recommends a facilitator’s tool: “parking lot” important but tangential discussions to address later, keeping the main meeting focused on its intended outcome.
  • Combat Over-engineering:
    • Kempck’s Design Rules: Simon recommends exploring these rules.
    • “Best Simple System for Now”: Daniel Turos North’s philosophy encourages building the simplest system that meets current needs, avoiding premature optimization.
  • Keeping Documentation Fresh:
    • Detail Only as Needed: “Document only in as much detail as you need because then you’ve got less to maintain,” Jacqui advises. High-level decisions change less frequently than low-level code details.
    • Automate Where Possible: For detailed documentation like APIs, use tools like OpenAPI to automatically update docs when code changes.
    • “Give Them a Link, Not the Answer”: Jacqui’s top tip: if people ask a question, provide a link to the answer. If the answer doesn’t exist, create it. If it’s outdated, update it. This creates a living, self-maintaining knowledge base.
    • “If code and documentation disagree, both are wrong.” (Quote attributed to Ruth Malan, among others).

🔄 The Feedback Loop: Design as a Living Process

How do you establish feedback loops once a decision is made, especially when new facts emerge during engineering?

  • DevOps at Scale: Simon views enterprise architecture as “one big feedback loop,” essentially DevOps at scale. This involves observing how systems perform in production using observability tools and understanding how decisions actually played out.
  • Continuous Collaboration: Jacqui emphasizes that feedback must flow both ways. Decisions from design affect architecture and engineering, but feedback from engineering must inform architecture, and architecture must inform design. “If it only ever goes down, then it’s not going to be successful.”
  • Incentivize Happiness: Sam points out that architects are often incentivized for having an architecture, not for making people happy with their decisions. Spending time with developers creates a “lovely forcing function” that naturally leads to better, more habitable designs.

The Ultimate Takeaway: Just Talk More! 🗣️

The entire discussion circled back to a fundamental truth: we just need to talk more. Software design, in all its forms, thrives on open communication, continuous collaboration, and a shared understanding of needs and decisions.

So, go forth, embrace decision records, foster dialogue, and remember: design is not a phase; it’s a continuous conversation that shapes the future of your software and the lives of those who build it. Let’s make it a great conversation!

Appendix