The Lost Art of Software Design • Simon Brown • YOW! 2019

This presentation was recorded at YOW! 2019. #GOTOcon #YOW
yowcon.com
Simon Brown - Author of "Software Architecture for Developers" & Creator of the C4 Software ‪@simonbrown4821‬
ABSTRACT
"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 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 of the lost art of software design, and how we can reintroduce it. [...]
RECOMMENDED BOOKS
Simon Brown • Software Architecture for Developers Vol. 2 • leanpub.com/visualising-softw...
David Farley • Modern Software Engineering • amzn.to/3GI468M
Dave Farley & Jez Humble • Continuous Delivery • amzn.to/3ocIHwd
Woods, Erder & Pureur • Continuous Architecture in Practice • amzn.to/2QWAmkl
George Fairbanks • Just Enough Software Architecture • amzn.to/3uZzVo0
/ gotocon
/ goto-
/ gotoconferences
#SoftwareArchitecture #DevOps #SimonBrown #Microservices #Monolith #ModularMonolith #Complexity #BoundedContext #C4Model #SoftwareEngineering #Programming #SoftwareDevelopment #UML #DRY #Structurizr #YOWcon
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
kzbin.info...

[@justwanderin847]

The Practical Guide to Structured Systems Design - Meilir Page-Jones; Modern Structured Analysis - Edward Yourdon; Complete Systems Analysis - James & Suzanne Robertson; Developing Structured Systems - Brian Dickinson. Old School

[@micahjesse6580]

Great talk loved it, but one thing the guys who uploaded didn't consider is that you can't scan the QR code at the end of the video simply because it's blocked by other video suggestions...yaaay

[@TNothingFree]

Great presentation! I've been dealing with design docs for years and wrote about this subject, Not enough is being done - many SE still choose not to properly design their work beforehand. Evolutionary design is good when you are not sure what is being done - or when something is going to change soon. Using the YAGNI principle you don't need to design more than you know currently. If you do - put it in the design because these aspects are going to answer the future SE whom would ask "Why did they do that". The design doc should be the answer .

[@crhayes]

I see the IGN rating system has made its appearance. 7:37

[@Dhamma12125]

What's a good alternative to UML and CASE considering those things have serious drawbacks

[@nyrtzi]

Depends on which drawbacks you're finding problematic. If your primary problem would be for example coworkers that aren't willing to put in even the 15 minutes required to learn a minimal subset of UML then it's not the diagramming method that's the problem.

[@thallysrc]

Very good content

[@oh2txb18]

Come from manufacturing industry. The idea of not having at least a guiding model (blueprint) sounds completely absurd to me. I very much like that this method is incredibly similar what I decided on, myself. You're not trying to micromanage every aspect, but not choosing a route just means you're driving around willy-nilly and likely wasting time/money having to change routes after having already done work.

[@kalleranki2226]

Not doing design is a backslash to having Enterprise architected fizzbuzzes caused by the OO software "design". Like we currently know the refactoring book can be replaced by a lambda expression.

[@davidyeung6647]

en.wikipedia.org/wiki/Erhu, the 2 string guitar might have worked.

[@alute5532]

1 decomposition techniques 2 modularity Workshops crc Why drsogn 1 enough upfront design To uncover unknown unknowns Notion of direction Teams rush in stuff Forget about (0really) obvious thinge All about technical leadership(0eotk with, not follow necessarily Conversations High level superficial upfront design Micro service architecture