Excellent presentation! I've seen this concept go by the name volatility-based decomposition (Juval Lowy), and as an approach it dates back to a famous paper on the criteria for decomposing a system into modules by David Parnas (1972), but it's great to see it presented in a fresh way and with the well-defined tie-in to complexity theory to help support it. I'd love to see a follow-up to this presentation that relates the theory more explicitly to some of those prior findings in the software architecture field to show the consistency.
These are completely different concepts. Both Parnas and Volatility Based Decomposition are referenced in the academic papers on residuality - and both these methods assume an ability to predict what will change and encapsulate it. This is not considered possible hence the need for complexity theory. Neither of these techniques address the key architectural question on non-functional requirements and are instead focused on use case analysis. In particular there is a focus on pattern based approaches for encapsulating volatility. Thus on a deeper level residuality has a very different philosophical approach that avoids the pitfalls of structural thinking that inform these two approaches. However, Parnas was right in pointing out the anti-patterns in decomposition. The extension of deterministic thinking to social systems is where the ideas part ways.
Great talk and great theory. I find hard to imagine working with the matrix for the systems I've worked with in the past due their size. Lots of columns and rows. How would one tackle handling a significantly larger system? I guess that bounded contexts are important to manage the size but even then...
This is done by partitioning the system, bounded contexts is a common way to do this. Any hyperliminal coupling across contexts can then be investigated in more detailed matrices. Even at the system level this can be used to get a picture across an entire company, but you shouldn’t have that many components rattling around without clear boundaries that it becomes impossible! In that case you need the matrices more than anyone…
Great talk. Nice to see a more detailed and educational approach to one way I tend to think things through when I approach a process. It's a great way to annoy the partner when approaching the questions she asked you aswell..😅
Man im at 43:20, completely mind blown by the insights into this mans head and all of a sudden i see that those two shadows of the spot lights make him look like an angel :D Haha this ist so funny i can't but giggle all the time he moves :D :D
This is a methodology which, given a small up front investment of thinking a bit, helps you separate the YGNI from the YAGNI stuff, which allows you to focus your time and energy on the stuff you do need, which in turn will increase your odds of long term survival. Practitioners of it have been eating YOLO'ers for breakfast for centuries.
@@seNick7 This turned into a looooong comment, sorry about that... It's the part where you go through the possible scenarios and come up with solutions. Let's take the charging stations again. Scenario 1: User wants to charge but payment system is down. Has many possible solutions but using a surveillance camera and reading plates by machine is one of them. Scenario 2: Someone using the station for too long? Use camera to read the plate, send bill. Scenario 3: Someone vandalizing the station? Not much you can do proactively but if you have a camera you can verify that the station is actually broken and not sending false alarms before going out to repair, and useful for the police report. etc etc. You soon realize that having security cameras with automatic plate reading would be awesome both for adding functionality, cutting costs, etc. If you were using the YAGNI approach and dealing with the payment system scenario afterwards you would have angry people with uncharged cars, people occupying the stations for days on end, kids beating the crap out of your boxes and no way for the police to help, sending out unnecessary techs to repair boxes that are not actually broken, and probably more. And you bet your ass that there are now people in four different teams each trying to come up with a solution to one of these specific problems; and odds are none of them own an electric car, have ever driven one, or will ever talk to an electric car owner before spending a year building some over engineered garbage that barely solves their own problem, let alone all four.
Utterly fascinating, great talk well done.
Excellent presentation! I've seen this concept go by the name volatility-based decomposition (Juval Lowy), and as an approach it dates back to a famous paper on the criteria for decomposing a system into modules by David Parnas (1972), but it's great to see it presented in a fresh way and with the well-defined tie-in to complexity theory to help support it. I'd love to see a follow-up to this presentation that relates the theory more explicitly to some of those prior findings in the software architecture field to show the consistency.
These are completely different concepts. Both Parnas and Volatility Based Decomposition are referenced in the academic papers on residuality - and both these methods assume an ability to predict what will change and encapsulate it. This is not considered possible hence the need for complexity theory.
Neither of these techniques address the key architectural question on non-functional requirements and are instead focused on use case analysis. In particular there is a focus on pattern based approaches for encapsulating volatility.
Thus on a deeper level residuality has a very different philosophical approach that avoids the pitfalls of structural thinking that inform these two approaches. However, Parnas was right in pointing out the anti-patterns in decomposition. The extension of deterministic thinking to social systems is where the ideas part ways.
A perfect talk for our actual business status. Kudos.
Taking notes...😅
A really interesting approach to systems design
Where can we track this ongoing research? Is there a site with guides for practitioners?
This looks alot like things that have been done in supply chain management over the last couple of decades, "Supply Chain Resilience".
Great talk and great theory. I find hard to imagine working with the matrix for the systems I've worked with in the past due their size. Lots of columns and rows.
How would one tackle handling a significantly larger system? I guess that bounded contexts are important to manage the size but even then...
This is done by partitioning the system, bounded contexts is a common way to do this. Any hyperliminal coupling across contexts can then be investigated in more detailed matrices. Even at the system level this can be used to get a picture across an entire company, but you shouldn’t have that many components rattling around without clear boundaries that it becomes impossible! In that case you need the matrices more than anyone…
Brilliant
Great talk. Nice to see a more detailed and educational approach to one way I tend to think things through when I approach a process. It's a great way to annoy the partner when approaching the questions she asked you aswell..😅
A-M-A-Z-I-N-G
Man im at 43:20, completely mind blown by the insights into this mans head and all of a sudden i see that those two shadows of the spot lights make him look like an angel :D Haha this ist so funny i can't but giggle all the time he moves :D :D
Looks like a try to formalize the standard approach of "what if" questions. I wonder if this theory will survive a collision with YAGNI.
This is a methodology which, given a small up front investment of thinking a bit, helps you separate the YGNI from the YAGNI stuff, which allows you to focus your time and energy on the stuff you do need, which in turn will increase your odds of long term survival. Practitioners of it have been eating YOLO'ers for breakfast for centuries.
@@glader88 How it/which part of it helps you separate YAGNI from YGNI?
@@seNick7
This turned into a looooong comment, sorry about that...
It's the part where you go through the possible scenarios and come up with solutions. Let's take the charging stations again.
Scenario 1: User wants to charge but payment system is down. Has many possible solutions but using a surveillance camera and reading plates by machine is one of them.
Scenario 2: Someone using the station for too long? Use camera to read the plate, send bill.
Scenario 3: Someone vandalizing the station? Not much you can do proactively but if you have a camera you can verify that the station is actually broken and not sending false alarms before going out to repair, and useful for the police report.
etc etc.
You soon realize that having security cameras with automatic plate reading would be awesome both for adding functionality, cutting costs, etc.
If you were using the YAGNI approach and dealing with the payment system scenario afterwards you would have angry people with uncharged cars, people occupying the stations for days on end, kids beating the crap out of your boxes and no way for the police to help, sending out unnecessary techs to repair boxes that are not actually broken, and probably more. And you bet your ass that there are now people in four different teams each trying to come up with a solution to one of these specific problems; and odds are none of them own an electric car, have ever driven one, or will ever talk to an electric car owner before spending a year building some over engineered garbage that barely solves their own problem, let alone all four.