The lost art of software design by Simon Brown

“Big design up front is dumb. Doing no design up front is even dumber.” This quote epitomises what I’ve seen during our journey from “big design up front” in the 20th century, to “emergent design” and “evolutionary architecture” in the 21st. In their desire to become “agile”, many teams seem to have abandoned architectural thinking, up front design, documentation, diagramming, and modelling. In many cases this is a knee-jerk reaction to the heavy bloated processes of times past, and in others it’s a misinterpretation and misapplication of the agile manifesto. As a result, many of the software design activities I witness these days are very high-level and superficial in nature. The resulting output, typically an ad hoc sketch on a whiteboard, is usually ambiguous and open to interpretation, leading to a situation where the underlying solution can’t be communicated, assessed, or reviewed. If you’re willing to consider that up front design is about creating a sufficient starting point, rather than creating a perfect end-state, you soon realise that a large amount of the costly rework and “refactoring” seen on many software development teams can be avoided. Join me for a discussion about the lost art of software design, and how we can reintroduce it to help teams scale and move faster.
SIMON BROWN
Simon is an independent consultant specialising in software architecture, and the author of “Software Architecture for Developers” (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He is also the creator of the C4 model for visualising software architecture, and the founder of Structurizr. Simon is a regular speaker at international software development conferences, and travels the world to help organisations visualise and document their software architecture.
------------------------------------------------------------
INTRO
* visuals & editing by @Mercator
* music : Avocado by Ephixa

[@papanito4802]

Very cool and refreshing talk. I think more people should see this video.

[@stefan-hoehn]

There is a good reason why this talk was rated as on of top ones during the conference. Simon really speaks from my heart. Can we please restart doing (not big) up front design and then iterate over and learn from it?
Thanks Simon!

[@avanishr]

Great talk, I am in the midst of working on a 2 year long project and only after the first 4 months of work did I realize that my risk prioritization was in whack. Getting perspectives from key stakeholders upfront as was suggested could have avoided some of the troubles

[@juniorwebd]

Great talk! Thank you very much!

[@kallaskaspar]

31:56 "A common set of abstractions is more important than a common notation." That's powerful!

[@danzaharescu2632]

Very nice talk ... you can easily fall into the trap set by Agile manifesto, because the main page advices about a way of working which is not totally wrong, but incomplete. The need for upfront design is unfortunately noted at bottom and the front page is heavily promoted in trainings. Thumbs up for the talk ... and let's hope Agile Manifesto will be upgraded some day. An eye opening talk indeed !

[@pauloperbone]

Awesome talk!

[@armenarz4062]

Thanks

[@emanuelerabino3909]

Thanks Simon for the talk, absolutely relevant.
I find myself completely in agreement with the arguments and it is a theme that I live on the skin every day in my work.
The big question is: how to address different sensitivities about "when to stop upfront design" in a team? Simon suggests a series of "goals", but imho they remain difficult to measure (for example: "you understand ... requirements").

[@carlwummel9050]

Hmm... maybe something like...
When count(currently unanswerable questions)/count(questions) < 0.2
So you discussed and clearified 80 questions and twenty remain.
Have a round of "Rate the criticality of uncertainty" for these 20. Decide to investigate it. Or guesstimate the risk (cost) of trial and error it.
The gut-feeling is still there, however, the whole point is to think about the stuff you do a "bit" more before starting to invest heavily in it. Goes back to the old saying of "the later an error is found the more expensive it is to fix it" or something like that.

[@shyamagrawal6161]

One of the best session .. Thanks Simon

[@SamTipton]

The lost art of software (diagram) design

[@PaulSebastianM]

19:08 LMFAO!

[@user-or2cx2zs8w]

Yeah, but can we address the elephant in the room - WHO PUTS A STRATOCASTER HEADSTOCK ON AN ACOUSTIC GUITAR?!

[@xtinctspecies]

I do not disagree with most of his stuff. But there is something in his talks that turns me off. Ridiculing things said to him for example or calling things garbage.

[@DF-ss5ep]

Yes. He's making it look like it's just obvious that you have to design things, and being weary of design is just stupid. It's not stupid, there is a reason for that. It may be wrong, or not, but there are good reasons behind it.

[@koskoz]

@@DF-ss5ep reasons like?

[@carlwummel9050]

​@@koskozmaybe overthinking? At least thats what I am cursed for 😄

[@viktoralferov2874]

22:27 How we can connect Angular to ORM? Easy - GraphQL.

[@kitkarson4226]

Boring talk!

[@mirageman2]

I expected a bit more hands on or some cool enlightning, maybe this comes somewhere after the first 10 minutes, that was just too abstract for me, but just my opinion.

[@koskoz]

So you're complaining but you haven't even watch 10 minutes?

[@quentinquaadgras]

lol just use code to design software. It is unambigious.

[@carlwummel9050]

It's so not. But I assume you did a joke - then it was funny 😉

[@purpinkn]

Agile killed software