The Lost Art of Software Design

Simon Brown is the author of a few architecture books, and does consulting about architecture.

What he's put together is mostly from anecdotal data here. This is not based on real research but it looks like he's done an awful lot of work to put this together.

A lot of what he's trying to describe is his Structurizr tool which helps you lay out the structure of your programs.

This is the first time I've seen someone use the Spotlight Presentation Remote in a presentation and it's pretty damn smooth.

Simon reflects on diagrams that he got people in his workshops to put together. They were swapped and rated by people who rated them all generally high, but he argues that they're not great generally.

Simon argues the value in architectural diagrams that look like your code base is that you can understand and evaluate it.

Simon suggests that Page 2 of the Agile Manifesto is far more interesting than Page 1 because it's got more details that you should care about.

A good architecture allows you to move fast. If you have something without good modularisation, then it ripples through your system.

Up front design is not necessarily about creating a perfect end state or complete architecture.

Simon gives a hat tip to a blog post Beginning With A Primitive Whole by Joshua Kerievsky who writes a lot about Agile on the Industrial Logic blog .

This argues the first version you ship needs to have some technical design like materials and extension points for the future. You don't just jump on the solution. Up front design is about having a direction or having a vision, and that might change. Our direction might change once we start getting feedback too, and that's fine.

Part of the design activity is about discovering the unknown unknowns. We're trying to figure out if it's not feasible or if we need to do more work.

33:00 Simon discusses his C4 model which has a set of diagrams that let you zoom in and zoom out at different levels of your architecture. They allow you to see different aspects and facets of your system.

34:25 Starting with a System Context Diagram which describes here's what you're building and the roles around it. This means actors, roles and personas of real users as well as other systems your system integrates with.

35:22 Then on to a Container Diagram which describes the higher level technology building blocks. What are the applications and data stores that come together to form our system? What are their responsibilities, and how do they communicate?

This is a feedback loop that lets you ask about how this works and why. You can challenge the design and get feedback.

38:29 Identify and mitigate your highest risks. Simon refers to a book called the Rational Unified Process from 20 years ago because we've already solved this. Front-load the risk into your lifecycle.