The Fundamentals Of Software Development | Martin Fowler In The Engineering Room Ep. 1
ฝัง
- เผยแพร่เมื่อ 2 มิ.ย. 2024
- Welcome to the Engineering Room, wide-ranging conversations with thought-leaders from the software engineering industry. This is a new mini-series of additional content on the Continuous Delivery Channel.
In this first episode, Dave Farley chats with Martin Fowler. Martin is a widely read author having written definitive works on several important topics, including Refactoring, NoSQL, UML, Extreme Programming, and several books on patterns. He also has a very widely read website that captures more of these thoughts, and more collections of patterns too at ➡️ martinfowler.com
Dave and Martin discuss a wide range of ideas, from new work in patterns in distributed systems and Data Mesh, to the fundamental principles of software development that matter, whatever the technology or problem that you are solving.
-------------------------------------------------------------------------------------
👕 T-SHIRTS
Do you like the t-shirts that I wear in my videos? YOU CAN SAVE £2 ON EACH ORDER from Qwertee via this link ➡️ bit.ly/3yUwvYC.
This Discount is only available for Continuous Delivery viewers!
🚨 DON'T FORGET TO USE OUR DISCOUNT CODE AT CHECKOUT: ContinuousDelivery
__________________________________________________________
📚 BOOKS:
🚨 MY NEW BOOK! 👉 📖 "Modern Software Engineering" is now available on
Amazon ➡️ amzn.to/3DwdwT3
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 JOIN CD MAIL LIST 📧
Keep up to date with the latest discussions, free "How To..." guides, events, online courses and exclusive offers. ➡️ bit.ly/MailListCD
-------------------------------------------------------------------------------------
⭐ SPONSORS:
This series is brought to you by Equal Experts.
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
-------------------------------------------------------------------------------------
VIDEO CHAPTERS
Intro to Martin Fowler - (00:00:00)
Patterns in Distributed Systems - (00:04:12)
“Data Mesh” Dealing with Data at Large Scale - (00:18:48)
How to Replace Legacy Systems - (00:34:09)
Addressing the Problems of the “Critical Aggregator Pattern” - (00:41:20)
Collecting Patterns or Offering Advice? - (00:47:45)
Self Testing Code - TDD As Fundamental Principle - (00:56:45)
Accelerate Books & DORA Metrics - (01:07:02)
Measurement - Sociology isn’t Physics - (01:10:14)
Software as Tracer-Bullets - (01:12:25)
Hardware & Safety Critical Systems - (01:14:38)
Wrap Up - (01:18:20) - วิทยาศาสตร์และเทคโนโลยี
![[TH] 2024 PMSL SEA GF D1 | Summer | แข่งที่ไทย ต้องใส่ให้สุด](http://i.ytimg.com/vi/Jkuf7nCS7jI/mqdefault.jpg)
Whooaa! Two LEGENDS in a single video!!! Thank you for sharing this legacy! :) :)
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.
" We are building tomorrow's legacy systems today " real talk 💯 true.
Reminds me of VersaLife's slogan
Much insight, such wow!
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!
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!
Really appreciate this format, looking forward to more of the same -- cheers
I'm very thankful for having this valuable content. Thanks Dave and Martin.
That was brilliant, thanks for sharing the conversation.
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
Holy f**k, what a well spent hour that was! So grateful for you sharing this! An absolute nugget!
I am so excited for this series, great job!
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 :)
Absolutely fantastic conversation. Love it!!!
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. 👍🏻
Thank you, Dave Farley and Martin Fowler.
Many thanks for this talk!!! I was happy to hear such a intresting and useful discussion
This is ABSOLUTLEY AMAZING.
I would love to see this as a podcast.
Thanks Martin and Dave, that was a pleasure to watch.
Loving this new series!
Really looking forward to this!
Great discussion! More, please!
Great and useful conversation! Thank you!
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.
💯💯😁😎
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
Would love for this series to be released as a podcast!
Top quality content, as usual.
This is awesome 👍
Amazing work !
being sympathetic... that's such good advice. ❤
Thank you Dr. Glassman
"I have enough knowledge to ask good questions and enough ignorance to ask good questions" Martin Fowler, 46:18
Interesting, instructive!
I need that book on legacy displacement patterns yesterday. Looking this up as he describes it, hoping to get a title.
The greatest of all, IMHO.
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
awesome sunday surprise
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.
Time is the fourth dimension and understanding is the fifth - brilliant. 29:24
- 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.
Very nice and insightful, thank you, I would only suggest to add subtitles for deaf people.
The Legend himself
What book does Martin refer when talking about replacing legacy systems?
Junit based on smalltalk port nice. What a great concept builder he is
Love to see a conversation with Uncle Bob
Should you use rebasing or merging when integrating your feature branch with main?
awesome!
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.
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
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).
Very interesting.
Ii bet the Fowler family line is proud, huh .
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
Would it be possible to upload this as a podcast to some platform (preferably Spotify)? Would love to listen to this during my walks
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.
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.
is that Sheffield Park in the background?
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.
Third book... I want it.
fundamentals? seems like a stretch to me. I do enjoy the conversation though.
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.
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.
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.
liked
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
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. ;-)
10:32
For the algo
😮
FusionWorks hires people straight out of college. Ouch. That hurts.
There's gotta be a fundamental principle that those Airpods are violating. Toothbrushes in ears don't clean.
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