“Industry Changing Book” | Reflecting On Continuous Delivery The Book | Jez Humble TER Ep. 20
ฝัง
- เผยแพร่เมื่อ 25 มิ.ย. 2024
- Jez Humble joins Dave Farley in the podcast episode where they discuss writing the award-winning book 'Continuous Delivery' - Jez' goal was to stop people wasting time by doing the wrong things, and showing people a better way of working so they don't have to spend their evenings and weekends to release new software! Dave and Jez share views on a divided SW industry, the real identity of a software developer, what mistakes they made, the importance of building teams with trust, the origins of TDD and Blue-Green deployment, current software engineering trends AND MORE.
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
___________________________________________
🙏The Engineering Room series is SPONSORED 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
___________________________________________
🖇 LINKS:
DORA - www.devops-research.com/resea...
Project Aristotle
___________________________________________
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 "Lean Enterprise: How High Performance Organizations Innovate at Scale" by Jez Humble, Barry O'Reilly, Joanne Molesky ➡️ amzn.to/39mC05b
📖 "Accelerate, The Science of Lean Software and DevOps" by Nicole Fosgren, Jez Humble & Gene Kim ➡️ amzn.to/2YYf5Z8
📖 "A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Agile Software Development)" ➡️ amzn.to/2YgZ7ss
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.
#continuousdelivery #softwareengineer #developer
------------------
CHAPTERS
00:00 Welcome to The Engineering Room
00:20 Introducing Jez Humble
02:23 The Goal of The Continuous Delivery Book?
06:35 A Divided Industry (Why are there still people who work on branches?)
08:53 The Identity of a Software Developer
11:05 Great developers solve problems in small steps
16:50 CD is State of the Art, building on Agile and Extreme Programming
21:32 The Origin of Blue-Green Deployments
27:43 Jez’ Mental Model for SW Dev
31:26 Making SW Easy to Change
35:07 TDD used For Mercury Flight Control SW
36:18 (Yes we’re both Space Nerds!)
38:20 Incremental Test-Driven Innovation is not just true for SW
40:21 Building Teams, Trust and Google's Project Aristotle
44:00 The Iron Triangle and the HP Lazerjet team
48:26 Behavioural Science and the DORA Metrics
55:15 Move Faster Safely = Move Safely Faster
57:52 Don’t Ask Permission to Test Your Code
1:00:18 What Should We Have Done Differently in the CD Book?
1:06:00 Thanks and Wrap Up - วิทยาศาสตร์และเทคโนโลยี
The Men Themselves! I'm thrilled to hear you both, the CD channel is one of the things that changed my perspective of software engineering. The "CD - Sounds great but it won't work here" talk by Jez Humble masterfully debunked all my criticism about CD, and pushed me to learning how to be a better engineer, more than my university.
I must say, you two give me the drive to pick up engineering and team management books in my free time, to perfect the build pipeline for my side projects, and to learn how to make small steps by thinking harder about what I want from my code before I write it by writing tests first.
These 2 guys changed (and are still changing) our industry you know...
Just like Kent Beck with XP (Extreme Programming) before them.
By the way: is there any good software engineering idea which does not have any link to or root in XP?!
😍Thanks to you both!!! Your book changed not just your careers but also the career of many of your readers.😍
Thank you!
I remember “that project” well and the conference. Inspirational times and days. Thanks for this Dave and Jez
You guys never fail to deliver in a timely fashion.
You could almost say... they deliver continuously 😉😂😂
I wrote a comment elsewhere recently that the era either side of the CD book was when Software Engineering felt most like Engineering. Clean code, unit testing, continuous integration, mocking, dependency injection, code as craft, incremental development etc. I know a lot of this is still used in the Java community, but it hasn't been adopted as widely in the JavaScript world which is a huge part of the industry nowadays. I think we've lost something as things have progressed.
Enjoyed the conversation anyway. The book and the ideas within it were hugely impactful on my career.
Would be really good to see a video exploring what Jez mentioned about Blaze/Bazel at 1:02:29 - You have videos in which you declare that software versioned together should be one deployable unit - but companies like Google clearly don't quite do that. At first glance Bazel seems to share a philosophy with CD - it helps get fast feedback by making complex builds faster - but upon further inspection, it seems to encourage a versioning and delivery design that is not fully compatible with CD. Would be really interesting to hear from Dave: either criticisms of the Bazel approach, or an explanation of why I'm wrong and it is in fact compatible.
Wow. Wow. Wow! This is amazing! I never clicked so fast on a video before!!! I read your book over and over, I can practically recite it chapter and verse.
Thanks, I am pleased that you liked the video and the book 😎
Looks like it is time for a revised edition of the book!
🫣
it's easy to get sentimental about the state of the industry at around the 5-6th minute
One important take from this conversation is something Dave already mentioned in other video that "most developers haven't work on good project" and people like Jeż and Dave are trying to change that. But there might be an issue with "scalability". As Dave commented once that it might take us mor than 100 years until we as an industry will be in the same place as aerospace when it comes to delivery quality and safe products. For me one of the reason is that not enough companies/developers are investing into right practices. Yes, everybody are Agile and DevOps right now, but not in the right way.
I'm currently looking for a new role and one of the criteria I apply is that I'm looking for an organisation with strong technical culture, which for me means for example that they are practicing Continues Delivery, or are writing technical blog to share knowledge. But there are not many companies who are doing it or they are not shouting about it loud enough.
Good luck in finding the right place, they are out there!
I can totally relate to facing the resistance of people when you introduce things like trunk-based development, they do indeed react like a personal attack, it blows my mind
And my answer was marked as spam because youtube is useless!!!
BTW, off topic, but on causation: there are ways to gather causal information from clinical trials - Bayes networks, for example. Also, I do think that the social and (what Bunge calls) mixed - (psychology, anthropology, perhaps even linguistics) sciences of software development are a wonderful idea and look forward to more of them. The causal modelling approaches just mentioned might be interesting here too!
Thanks!
Thank you! That is much appreciated and very kind.
You guys are living legends. You're up there with the likes of DeMarco, Brooks, and Yourdon
Gosh! Thanks 😳
31:15 talking about tacit knowledge, the intuitive subconscious automatic parts that are hard/impossible to put into words... there's a recent book "Badass: Making Users Awesome" that's stealthily about the science of expertise. Aino would really like that one I think. It includes the idea of learning through exposure, how we can just pick up on things deep-learning style through seeing many diverse examples of the different kinds of "good", and our brains can subconsciously catch onto the hidden deeper patterns. Like mentioned in tge beginning, many of us have never been exposed to "good" in the first place. Then, for those how have, it's obviously and intuitively good - because we have acquired that experiential perceptual knowledge and have become able to see it (and in the habit of looking for it)
Uh, I will find that book, thank you! ... just found it, and of course it is Kathy Sierra from the "Head first" series 🙂
@@ainocorry3004 I agree this is a great book, I have a signed copy of it from the very awesome Kathy :D
At 8:51 Jez says he has theory about why people are so wedded to not doing continuous integration. One of my favourite twitter threads used to be from Jez extolling this theory - written in response to a blog post from Dave, and also describing Git Flow as the acme of systematising in a bad way. Jez is no longer on Twitter so I can't link to that thread any more, and I sadly didn't save my own copy.
It would be great if there's any way it could be republished somewhere else.
6:13 share this part with your colleagues and managers.
On the topic of "everyone still uses maven", we used to use gradle but switched back to maven because gradle had an extremely annoying incremental compilation bug that would falsely trigger a clean build instead of an incremental build, wasting minutes of our time many times throughout the day. Maven has never had this issue, and as of my latest check of the most recent gradle version, the issue is still present in gradle.
Did you contact them and report the bug?
@@brownhorsesoftware3605 they've had an open issue for years for it
Dave, I'm hoping you'll interview my former mentor, and co-inventor of mock objects, Tim Mackinnon soon. He is full of great ideas and an inspiration to many.
Tim is an old friend of mine, thanks for the suggestion.
most gradle projects i witnessed devolved into applications of their own in ugly ways. put someone in a legacy maven project and they will find their way around. cannot say the same for gradle, sadly. i was optimistic about gradle initially, but found maven a better fit for most stuff i do today. the data also supports this. the majority uses maven, even for new projects. only gripe i have with maven is, that it does not support incremental builds like every other tool before it, like make. its wasteful by default. running mvn test twice without changes should really only run once since there are no changes, yet it recompiles everything again.
Now i got the final confirmation: software engineering is a social science, and not a technical science (anymore)
Why does everyone of my comments get marked as spam?
I've never worked anywhere that quoted anything from Dora.
I feel for anyone who is still forced to program in Java. Those who choose it deliberately are insane.
I don’t use Java but I’m curious what your preferred language is.
I feel that way about C++. The aspect of Java that I do not like is the JVM. The language is solid and the libraries are robust. C# is a Microsoft technology. Go hits the right combination for me.
@@esra_erimez I love C#, especially since it's been open-sourced years ago and its connection with Microsoft isn't what it used to be.
@@vargonian I agree, I think C# is superb. But, I can't get past the Microsoft thing.
A lot of subjective opinions in this video, and a lot of dogmatism
Not really, most, if not all, of them are backed by the research that we describe from DORA.
It is also not dogmatic if we are willing to change to something better, as we explicitly discuss in this video.
"Dogma: Dogma in the broad sense is any belief held unquestioningly and with undefended certainty"
By definition, we aren't holding views "unquestioningly" if we question them and explore and consider the alternatives. If we refute the alternatives, based on evidence, that isn't dogma, that is science and engineering!
I can also give you a rational reason for every practice, why it matters, and why it works better than the alternative, that I promote, so it isn't "undefended" either. Of course, I may be wrong, and you may disagree, but neither of those things say that I, or Jez, are being "dogmatic".
There is certainly no "100% proof" here if that is what you mean, of course it is possible to build software without Continuous Delivery, but the data from the most scientifically defensible research into SW dev practice says that if you don't practice CD you have a significantly lower chance of success, which is why many, maybe most, of the most successful SW companies in the world work this way.
Statistically, if you don't do these things, the chances are that you produce worse software slower! That isn't subjective or dogma, that is what the data says, if you want to challenge that, here is a video that tells you what you need to do to refute these ideas: th-cam.com/video/pAX8GAsRaYk/w-d-xo.html