A very humble man; to be able to put these various concepts and ideas into coherent packages is an incredibly under-valued skill. As Feynman said (paraphrasing here) being able describe things clearly and concisely to those with varying levels of expertise, shows true knowledge of the subject.
Trust me, Martin Fowler, Uncle Bob and the rest of these clowns are not in the same league as Richard Feynman. For one, none of them have done anything other than wrote opinion pieces, sold courses and spoke at conferences. Zero evidence of success from any of these people. Perhaps Trump University is a reasonable analogy.
I love these insights: as someone who's currently working within a massive, unwieldy, legacy enterprise framework on a project which is years behind schedule, it's great to step back and think about (a) how we got here and (b) what the alternatives are. Even if I'm currently powerless to change it!
It's so great seeing such a huge personality interviewed here on this channel! Can't wait to see the other episodes of this mini-series, keep up the good work!
Just as I was searching for some good podcasts on software architecture and development, you drop this. Thanks for starting this series, I am really looking forward to more of these
I've been following your channel for a while, and have been working towards a "continuous delivery" model in my own programming (I do full stack online game development in C.) This new sub series is GREAT! Martin Fowler was awesome, and I certainly need to visit his web site often now. I think my favorite part of this interview was the section where he talks about the "mental switch" flipping in the context of forgoing branching in favor of ensuring that the code is released in small, incremental bits whose jobs are to "not break the system" and "push the new feature by a small increment." I've been doing this for a while now after watching your "Don't branch" videos. At first, it felt like I was committing useless code that did nothing... with the first commit simply a shell of the first functions I thought I would need... but the value is not only me telling others what I'm working on and how I think I will do it, but me being able to bring in the incremental commits of others telling me what they're doing and how they think it will work.
This one is so much about context: E.g branching discussion: feature branching & pull requests works well on FOSS (they invented it and FOSS tends to expect a feature more or less complete once somebody comes up with it) but is an anti-pattern in fully-paid-developer 'continuous' environments. Have to: Your channel opened my eyes. As a one-man show for decades now: Manual tests only and yeah I am good at them at the time of implementing new. This won't work further decades (and there are ageing constraints but I am optimist on that). Sometimes I wonder if I hung up with the wrong guys (don't tell them or not really :)
I certainly always do, but have unlimited internet and just put up the video. I second the idea of just publishing the audio for others who are not so keen on spending the mb's on playing a video and just listening to it
Wow how are you going to top Martin Fowler for your next talk? This was a fascinating discussion, really enjoy listening to the heavyweights / founding fathers / gods of our industry chatting about thins that clearly interest them.
- Every system should become its own silo from the outset. This allows for full control over the entire scope of the system throughout its life cycle. This guarantees the correct context is locked in. - Every system should require distributed citizens only, in the terms of classes, packages and solutions. This allows for full flexibility at every point with the least amount of cost, be it time, human resources, physical resources, etc. This also allows for substitution which yields scaling capabilities and potential which we all know will inevitably reveal itself at some point in the future. This is also the key to unlocking the ability for far greater code reuse and this makes everyone's lives much simpler and reduces workload.
I think that coupling is more complex than that. It is a tool that we use, there are some times when loose-coupling, as you describe, matters a lot. There are others when it is sensible for things be more tightly-coupled. I think that the best guide for choosing repo boundaries, for example, is deployability - can you imagine deploying the system that you work on without testing it with anything else? If not, then multiple repos get in your way and slow you down. The risk of "siloing" at too small a level (less than independently deployable) is that you can only go slower, so you get worse feedback on your work. Distribution by default is risky too. You would be crazy to define a distributed interface to something processed a character at a time (I saw people do this with EJBs and CORBA many years ago, so this isn't a made-up case). There is a cost to communicating over a network vs local calls, and sometimes that cost can be excessive.
I genuinely love your channel. Just love the conversations you have and the topics you cover. All of your videos are amazing, and I feel very blessed for you to share them. 👍🏻
Everyone must chose between 'the quick and easy' or 'the slow and simple'. In the moment the allure of 'the quick and easy' will capture the attention of most. In the long run, 'the slow and simple' can vastly outperform the alternative and often with pleasantly surprising results that were otherwise unforeseen.
Just recently I've seen tweet that someone have seen Person class with 7k fields. I think it was one of the aggregated view of a Person from different parts of organisation similsr to a Customer you and Martin were talling about when discussing Data Mesh
I wanted some guidance on whether should I pursue Software Development career. Because I hear this from people that AI is going to replace humans in Software development. I wanted your take on this.
Can you ask Fowlers opinion on when to use Unittests and when to use Integration tests? What gives the best freedom when refactoring? What is the pros/cons of each? Thanks :-)
I can tell you what I think, do TDD for unit tests, write the tests first, and only do integration tests tactically where they give you faster feedback on something you can't learn from a unit test. Structure all of this with higher-level, scenario based Acceptance tests (see some of my videos here for how and why).
1:00:04 thats exactly what i do. spiking and all that. and what not. once i am certain i start investing more time. for rust, for flutter, dart. and even rn for go lang. and k8s operator. testing support is the first thing i do... cause thats the only way i can write. do tdd...
and one of the most beautiful thing i find about tdd is, esp it is, watching the test fail for the right reason... in intergration tests thats hard. but once you see it fail for the right reason. its just a matter of you make it green.
On the data mesh topic, take multiple distributed sources for streams and then submit it to a central authority that does "business intelligence"... and what you eventually create is just a datawarehouse with the data fed in clean formats by their domain data owners. Am I wrong?
It sounded more like Fowler was describing something more akin to microservice/SoA approach to data feeds, where rather than having everything in a perfect data warehouse in the middle, the point in the middle is a place for discovering the sources that would have been feeding it (kind of like service discovery in microservice systems). That way, you're not tackling an unnecessary problem of trying to choose which bounded contexts the central warehouse uses(as well as normalising in other ways such time series, sampling rate, etc), but instead let the people pulling the data choose to get the data right from the source, bounded context and all.
The fundamental of software design is the hiring of good software engineers. That is the one and only problem here: you can't find them in an industry that is 50% newbies, 30% middle manager wannabes and 20% burned out experienced people who would rather sift through trash all day long than work one more day in a software development team with 50% newbies and 30% middle manager wannabes. ;-)
Can you provide a link of article of Tesla continuous delivery sample you mentioned at 01:17:30 ? It is a great sample to send colleagues to show the power of tdd
Honestly this seemed like a really long ad for different books he has going on. Definitely different from what I was expecting. I have his books already, I thought this talk would be more concrete. There was maybe one time that he went into some detail.
@@MrAbrazildo Sure, but CD doesn't add the complexity, running on different computers does. If you run SW on a single computer, it is likely to all be there and all be working or not. Run on separate computers, and sometimes it is all there and sometimes it is not.
Going back to Martin's original point about not distributing. I reckon most systems now developed as distributed microservices (because that's what Spotify et al with squillions of users do) would be easier to build, maintain and run as n-tier relational database based systems. If most business software was like this then most businesses wouldn't need data lakes, meshes or pipelines, just a simple BI reporting tool.
I don't get it, I work at a big Corporation I can't just waltz right in and change only my squad way of working, and this video seems to say you either do XP or you are not doing ci correctly
I know, but the data says that the ability of your "squad" or team to make such choices is a predictor of success. The fact that you can't make that choice says that you are, statistically, probably not doing as good a job as you could be. That's a big problem, and it is possible that you can't change it, but that's what the data says. If as an individual you care about these think you now have a choice. To quote Martin Fowler from another tome, "You either decide to change the company that you work in, or you decide to change the company that you work in". It's a joke, but there is some truth in it. The trouble with big corporations is that they can, and often do, create cultures that are not optimised for doing a good job and it is incredibly complex, sometimes (but not always) impossible, to change them. The good news is that most orgs don't want to be in that position, and the good ones value people who try to change things for the better. So you could look to see how you could, first, make the situation for you and then in your team as good as you can - what things are in your direct control. Fix them first. Then figure out what things that are wrong can you influence other people to change? That is you next place to try an improve things. It is hard, but that is how org change works.
there is a lot more math and "proving" in sociology than in a lot of "non-experimental" physics that is fashionable today ... was going find until this point; sociologists can regularly predict outcomes in chaotic systems (elections for example)
Sure, but is statistical, which is also true of Physics, but most people, I think, think of Classical physics, which is not so heavily based on probability.
@@ContinuousDelivery so statistics is not real Math or true Math ? ... too bad then, a lot of what happens in real life is powered by statistics, and very few actually understanding even the basics of statistics, probability and sampling is what is causing a lot of the problems humans have now
@@EmilNicolaiePerhinschi No it's real maths, but the output are probabilities not certainties, which is not what most people expect or think of about science. Let's be clear, "most people" are wrong in that assumption, but that is what we were discussing when talking about the DORA report the results are statistical and probabilistic.
Too much bla bla tbh. Not much said. Books, this and that... I am an experienced software engineer, I hope I can judge. Disappointed in Fowler, I am not talking about Dave.
There are plenty of people with 10+ years experience that seriously lack fundamentals. Honestly, in my experience it is most. And considering your attitude of "books, this and that", sounds like you probably fall into that camp too.
Hmm... Yes, books are mentioned, but they do discuss the design/architecture patterns and the problems that those patterns are supposed to solve during the talk. Perhaps you are not at that level yet where you are not interested in learning or having the need to know that patterns and therefore it's less interesting to you. I found the conversation fascinating and am learning some stuffs from it since I am dealing with the things that they are talking about (integration, data source of truth, etc.)
Software engineering has transformed from getting a job done to sitting around and waxing philosophical about all sorts of fluffy BS and Scrum this and Agile that, ad nauseam. So much time and money wasted sitting in stand-up circles and meetings and not writing any code. This video could be about socialism with very few changes to the vocabulary.
Yeah sure - lets all sit down and “get stuff done” - what happens when 2 people do “stuff” differently in a team? What about 2 teams? 2 separate departments? When people are not on the same page? What happens when work and feedback is not sought and tracked? What happens when teams corner themselves into a solution and makes it impossible to get out of, requiring a complete rewrite? The smaller the organisation, the easier it is to just “get stuff done” - the bigger the organisation/product, the more care and thought is required for every decision - and its the latter that this conversation is mostly about The literature on the above is quite intense - I remember this DevOps report estimating that there are billions and trillions of $ lost each year with dysfunctional organisations that are unable to align the customer needs, products and teams, being able to quickly find out whats required on the market, have a streamlined approach to introducing features and being “agile” enough to gather feedback and re-adjust
Also, a very side note - their ability to speak endlessly and in depth about all these topics highlight how elegant and knowledgeable they really are - its easy to see it as a narcissistic, egotist discussion - but its not They’ve been doing it for decades and are extremely thoughtful about the industry as a whole
" We are building tomorrow's legacy systems today " real talk 💯 true.
Reminds me of VersaLife's slogan
Much insight, such wow!
A very humble man; to be able to put these various concepts and ideas into coherent packages is an incredibly under-valued skill. As Feynman said (paraphrasing here) being able describe things clearly and concisely to those with varying levels of expertise, shows true knowledge of the subject.
Trust me, Martin Fowler, Uncle Bob and the rest of these clowns are not in the same league as Richard Feynman. For one, none of them have done anything other than wrote opinion pieces, sold courses and spoke at conferences. Zero evidence of success from any of these people. Perhaps Trump University is a reasonable analogy.
Whooaa! Two LEGENDS in a single video!!! Thank you for sharing this legacy! :) :)
I love these insights: as someone who's currently working within a massive, unwieldy, legacy enterprise framework on a project which is years behind schedule, it's great to step back and think about (a) how we got here and (b) what the alternatives are. Even if I'm currently powerless to change it!
It's so great seeing such a huge personality interviewed here on this channel! Can't wait to see the other episodes of this mini-series, keep up the good work!
Just as I was searching for some good podcasts on software architecture and development, you drop this. Thanks for starting this series, I am really looking forward to more of these
I've been following your channel for a while, and have been working towards a "continuous delivery" model in my own programming (I do full stack online game development in C.) This new sub series is GREAT! Martin Fowler was awesome, and I certainly need to visit his web site often now. I think my favorite part of this interview was the section where he talks about the "mental switch" flipping in the context of forgoing branching in favor of ensuring that the code is released in small, incremental bits whose jobs are to "not break the system" and "push the new feature by a small increment."
I've been doing this for a while now after watching your "Don't branch" videos. At first, it felt like I was committing useless code that did nothing... with the first commit simply a shell of the first functions I thought I would need... but the value is not only me telling others what I'm working on and how I think I will do it, but me being able to bring in the incremental commits of others telling me what they're doing and how they think it will work.
💯💯😁😎
Holy f**k, what a well spent hour that was! So grateful for you sharing this! An absolute nugget!
Really appreciate this format, looking forward to more of the same -- cheers
Thank you, Dave Farley and Martin Fowler.
This one is so much about context: E.g branching discussion: feature branching & pull requests works well on FOSS (they invented it and FOSS tends to expect a feature more or less complete once somebody comes up with it) but is an anti-pattern in fully-paid-developer 'continuous' environments.
Have to: Your channel opened my eyes. As a one-man show for decades now: Manual tests only and yeah I am good at them at the time of implementing new. This won't work further decades (and there are ageing constraints but I am optimist on that).
Sometimes I wonder if I hung up with the wrong guys (don't tell them or not really :)
Hey Dave, have you ever considered releasing audio from your videos as a podcast? I'd love to listen to those in a car.
I certainly always do, but have unlimited internet and just put up the video. I second the idea of just publishing the audio for others who are not so keen on spending the mb's on playing a video and just listening to it
Thank you Dr. Glassman
I would love to see this as a podcast.
Wow how are you going to top Martin Fowler for your next talk?
This was a fascinating discussion, really enjoy listening to the heavyweights / founding fathers / gods of our industry chatting about thins that clearly interest them.
Invite Eric Evans
- Every system should become its own silo from the outset. This allows for full control over the entire scope of the system throughout its life cycle. This guarantees the correct context is locked in.
- Every system should require distributed citizens only, in the terms of classes, packages and solutions. This allows for full flexibility at every point with the least amount of cost, be it time, human resources, physical resources, etc. This also allows for substitution which yields scaling capabilities and potential which we all know will inevitably reveal itself at some point in the future. This is also the key to unlocking the ability for far greater code reuse and this makes everyone's lives much simpler and reduces workload.
I think that coupling is more complex than that. It is a tool that we use, there are some times when loose-coupling, as you describe, matters a lot. There are others when it is sensible for things be more tightly-coupled. I think that the best guide for choosing repo boundaries, for example, is deployability - can you imagine deploying the system that you work on without testing it with anything else? If not, then multiple repos get in your way and slow you down. The risk of "siloing" at too small a level (less than independently deployable) is that you can only go slower, so you get worse feedback on your work.
Distribution by default is risky too. You would be crazy to define a distributed interface to something processed a character at a time (I saw people do this with EJBs and CORBA many years ago, so this isn't a made-up case). There is a cost to communicating over a network vs local calls, and sometimes that cost can be excessive.
I'm very thankful for having this valuable content. Thanks Dave and Martin.
Would love for this series to be released as a podcast!
Love to see a conversation with Uncle Bob
That was brilliant, thanks for sharing the conversation.
I genuinely love your channel. Just love the conversations you have and the topics you cover. All of your videos are amazing, and I feel very blessed for you to share them. 👍🏻
Everyone must chose between 'the quick and easy' or 'the slow and simple'. In the moment the allure of 'the quick and easy' will capture the attention of most. In the long run, 'the slow and simple' can vastly outperform the alternative and often with pleasantly surprising results that were otherwise unforeseen.
This is ABSOLUTLEY AMAZING.
Time is the fourth dimension and understanding is the fifth - brilliant. 29:24
Many thanks for this talk!!! I was happy to hear such a intresting and useful discussion
being sympathetic... that's such good advice. ❤
Thanks Martin and Dave, that was a pleasure to watch.
Junit based on smalltalk port nice. What a great concept builder he is
"I have enough knowledge to ask good questions and enough ignorance to ask good questions" Martin Fowler, 46:18
Absolutely fantastic conversation. Love it!!!
Just recently I've seen tweet that someone have seen Person class with 7k fields. I think it was one of the aggregated view of a Person from different parts of organisation similsr to a Customer you and Martin were talling about when discussing Data Mesh
I need that book on legacy displacement patterns yesterday. Looking this up as he describes it, hoping to get a title.
Very nice and insightful, thank you, I would only suggest to add subtitles for deaf people.
I wanted some guidance on whether should I pursue Software Development career. Because I hear this from people that AI is going to replace humans in Software development. I wanted your take on this.
Would it be possible to upload this as a podcast to some platform (preferably Spotify)? Would love to listen to this during my walks
The greatest of all, IMHO.
Very interesting.
Ii bet the Fowler family line is proud, huh .
Can you ask Fowlers opinion on when to use Unittests and when to use Integration tests? What gives the best freedom when refactoring? What is the pros/cons of each? Thanks :-)
I can tell you what I think, do TDD for unit tests, write the tests first, and only do integration tests tactically where they give you faster feedback on something you can't learn from a unit test. Structure all of this with higher-level, scenario based Acceptance tests (see some of my videos here for how and why).
Should you use rebasing or merging when integrating your feature branch with main?
awesome sunday surprise
Great discussion! More, please!
1:00:04 thats exactly what i do. spiking and all that. and what not. once i am certain i start investing more time. for rust, for flutter, dart. and even rn for go lang. and k8s operator. testing support is the first thing i do... cause thats the only way i can write. do tdd...
and one of the most beautiful thing i find about tdd is, esp it is, watching the test fail for the right reason...
in intergration tests thats hard. but once you see it fail for the right reason. its just a matter of you make it green.
Great and useful conversation! Thank you!
I am so excited for this series, great job!
On the data mesh topic, take multiple distributed sources for streams and then submit it to a central authority that does "business intelligence"... and what you eventually create is just a datawarehouse with the data fed in clean formats by their domain data owners. Am I wrong?
It sounded more like Fowler was describing something more akin to microservice/SoA approach to data feeds, where rather than having everything in a perfect data warehouse in the middle, the point in the middle is a place for discovering the sources that would have been feeding it (kind of like service discovery in microservice systems). That way, you're not tackling an unnecessary problem of trying to choose which bounded contexts the central warehouse uses(as well as normalising in other ways such time series, sampling rate, etc), but instead let the people pulling the data choose to get the data right from the source, bounded context and all.
This is awesome 👍
Third book... I want it.
What book does Martin refer when talking about replacing legacy systems?
is that Sheffield Park in the background?
The Legend himself
Really looking forward to this!
Loving this new series!
fundamentals? seems like a stretch to me. I do enjoy the conversation though.
The fundamental of software design is the hiring of good software engineers. That is the one and only problem here: you can't find them in an industry that is 50% newbies, 30% middle manager wannabes and 20% burned out experienced people who would rather sift through trash all day long than work one more day in a software development team with 50% newbies and 30% middle manager wannabes. ;-)
Top quality content, as usual.
Can you provide a link of article of Tesla continuous delivery sample you mentioned at 01:17:30 ? It is a great sample to send colleagues to show the power of tdd
Interesting, instructive!
Amazing work !
awesome!
Honestly this seemed like a really long ad for different books he has going on. Definitely different from what I was expecting. I have his books already, I thought this talk would be more concrete. There was maybe one time that he went into some detail.
Legend 🙏
54:00, does the "healthy enough state" (to integrate) means when the code has not error at compile time or runtime? 54:30, just a stable build, right?
Yes, it compiles and all tests pass.
8:43, by distribution do you mean to release the app (or code?) to the public?
No, it means software running on multiple computers - distributed computing.
@@ContinuousDelivery At the same time?
@@MrAbrazildo Sure, but CD doesn't add the complexity, running on different computers does. If you run SW on a single computer, it is likely to all be there and all be working or not. Run on separate computers, and sometimes it is all there and sometimes it is not.
Going back to Martin's original point about not distributing. I reckon most systems now developed as distributed microservices (because that's what Spotify et al with squillions of users do) would be easier to build, maintain and run as n-tier relational database based systems.
If most business software was like this then most businesses wouldn't need data lakes, meshes or pipelines, just a simple BI reporting tool.
I don't get it, I work at a big Corporation I can't just waltz right in and change only my squad way of working, and this video seems to say you either do XP or you are not doing ci correctly
I know, but the data says that the ability of your "squad" or team to make such choices is a predictor of success. The fact that you can't make that choice says that you are, statistically, probably not doing as good a job as you could be. That's a big problem, and it is possible that you can't change it, but that's what the data says. If as an individual you care about these think you now have a choice. To quote Martin Fowler from another tome, "You either decide to change the company that you work in, or you decide to change the company that you work in". It's a joke, but there is some truth in it.
The trouble with big corporations is that they can, and often do, create cultures that are not optimised for doing a good job and it is incredibly complex, sometimes (but not always) impossible, to change them.
The good news is that most orgs don't want to be in that position, and the good ones value people who try to change things for the better. So you could look to see how you could, first, make the situation for you and then in your team as good as you can - what things are in your direct control. Fix them first. Then figure out what things that are wrong can you influence other people to change? That is you next place to try an improve things. It is hard, but that is how org change works.
there is a lot more math and "proving" in sociology than in a lot of "non-experimental" physics that is fashionable today ... was going find until this point; sociologists can regularly predict outcomes in chaotic systems (elections for example)
Sure, but is statistical, which is also true of Physics, but most people, I think, think of Classical physics, which is not so heavily based on probability.
@@ContinuousDelivery so statistics is not real Math or true Math ? ... too bad then, a lot of what happens in real life is powered by statistics, and very few actually understanding even the basics of statistics, probability and sampling is what is causing a lot of the problems humans have now
@@EmilNicolaiePerhinschi No it's real maths, but the output are probabilities not certainties, which is not what most people expect or think of about science. Let's be clear, "most people" are wrong in that assumption, but that is what we were discussing when talking about the DORA report the results are statistical and probabilistic.
Durable idea =? Computer science
FusionWorks hires people straight out of college. Ouch. That hurts.
😮
10:32
liked
There's gotta be a fundamental principle that those Airpods are violating. Toothbrushes in ears don't clean.
For the algo
Too much bla bla tbh. Not much said. Books, this and that... I am an experienced software engineer, I hope I can judge. Disappointed in Fowler, I am not talking about Dave.
Just curious, do you maybe practice time travel or maybe consume some youth elixir that makes you younger than you actually are?
@@miletacekovic Its an older photo, rodjak, plus I look younger. I am 33 and have 11+ years of professional international experience. Cheers
There are plenty of people with 10+ years experience that seriously lack fundamentals. Honestly, in my experience it is most. And considering your attitude of "books, this and that", sounds like you probably fall into that camp too.
Hmm... Yes, books are mentioned, but they do discuss the design/architecture patterns and the problems that those patterns are supposed to solve during the talk. Perhaps you are not at that level yet where you are not interested in learning or having the need to know that patterns and therefore it's less interesting to you. I found the conversation fascinating and am learning some stuffs from it since I am dealing with the things that they are talking about (integration, data source of truth, etc.)
Software engineering has transformed from getting a job done to sitting around and waxing philosophical about all sorts of fluffy BS and Scrum this and Agile that, ad nauseam. So much time and money wasted sitting in stand-up circles and meetings and not writing any code. This video could be about socialism with very few changes to the vocabulary.
Yeah sure - lets all sit down and “get stuff done” - what happens when 2 people do “stuff” differently in a team? What about 2 teams? 2 separate departments? When people are not on the same page?
What happens when work and feedback is not sought and tracked?
What happens when teams corner themselves into a solution and makes it impossible to get out of, requiring a complete rewrite?
The smaller the organisation, the easier it is to just “get stuff done” - the bigger the organisation/product, the more care and thought is required for every decision - and its the latter that this conversation is mostly about
The literature on the above is quite intense - I remember this DevOps report estimating that there are billions and trillions of $ lost each year with dysfunctional organisations that are unable to align the customer needs, products and teams, being able to quickly find out whats required on the market, have a streamlined approach to introducing features and being “agile” enough to gather feedback and re-adjust
Also, a very side note - their ability to speak endlessly and in depth about all these topics highlight how elegant and knowledgeable they really are - its easy to see it as a narcissistic, egotist discussion - but its not
They’ve been doing it for decades and are extremely thoughtful about the industry as a whole