Kent Beck On The FIRST Testing Frameworks, TDD, Waterfall & MORE | The Engineering Room Ep. 16
ฝัง
- เผยแพร่เมื่อ 12 มิ.ย. 2024
- In this episode of the Engineering Room, Dave Farley and Kent Beck have a wide-ranging discussion about the return of waterfall development in software, TDD, Software Design and lots of other things along the way.
Kent Beck is the first signatory of the Agile Manifesto. He is the author of the industry-changing book "Extreme Programming Explained". Kent popularised Continuous Integration and TDD and wrote the first version of xUnit, the unit testing framework that has informed the design of unit testing frameworks ever since.
It is hard to imagine people who aren't familiar with Kent Beck's work, but even if that is the case, his work has had an impact on how you think about, and practice software development and software engineering.
--------------------------------------------------------------------------------------
🖇 LINKS:
🔗 "TCR (Test && Commit || Revert)", Kent Beck: ➡️ • TCR test && commit || ...
🔗 "Tidy First", Kent Beck: ➡️ tidyfirst.substack.com
🔗 Small Steps - "Explore, Expand, Extract", Kent Beck: ➡️ • Video
--------------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
-------------------------------------------------------------------------------------
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
_____________________________________________________
📚 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
📖 "Test Driven Development: By Example (The Addison-Wesley Signature Series), Kent Beck" ➡️ amzn.to/2NcqgGh
📖 "Extreme Programming Explained: Embrace Change", Kent Beck ➡️ amzn.to/3K5fhg6
📖 "Implementation Patterns (Addison-Wesley Signature Series (Beck))", Kent Beck ➡️ amzn.to/3K4VWvz
📖 "Smalltalk Best Practice Patterns", Kent Beck ➡️ amzn.to/3JKyfYg
-------------------------------------------------------------------------------------
🙏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
______________________________________________________
CHAPTERS
0:00 Welcome
0:30 Introducing Kent Beck: Reputation and Repetition
3:15 Unrealised Potential of SW Dev
4:34 Is Waterfall is Back?
8:17 “Wouldn’t it be easier if you did it right first time?!”
9:40 From Agile to Infinity
12:03 The Value and Discomfort of Discovery
14:12 Focus on Learning
16:25 Rediscovery of TDD
20:52 Represent Tests in the Source Code (“one of my best ideas”)
23:52 “Have you tried TCR yet”
27:37 TDD improves design, specification and developer well-being
30:04 Separate Behaviour and Structure
33:50 Small Steps and Get Feedback in 10 seconds
38:43 The Succession Problem - we don’t talk about it
42:08 There’s Never One Way to do Things
47:27 Designing for Complexity and Change
49:34 The Trade-Off between Predicted and Revealed Value
50:46 Motivation to Write a New Book Series
53:34 Software Design is an Exercise in Human Relationships
57:22 Writing “Tidy First?” and other books
1:06:16 Conclusion - Try Stuff! - วิทยาศาสตร์และเทคโนโลยี
![บุกร้านไอศกรีม VJ วุ้นเส้น !!!! [ดูคลิปเต็มหน้าช่อง] #Short | PANG ORNHIRA](http://i.ytimg.com/vi/g549nEhKZdc/mqdefault.jpg)
Want to learn how to do TDD? I have a FREE tutorial, where you can practise the techniques along with me, here: courses.cd.training/courses/tdd-tutorial
The legend himself, Kent Beck.
JUST Kent Beck!!! Incredible
Two legends in one frame. Absolute honor to listen to them. Thank you for teaching us.
Dave Farley interviews Kent Beck. My day has been made. Thank you!
Every time Dave hesitates in interviews it reminds me how well written and delivered the scripted videos are and I am impressed by the amount of work it must be to do this at the pace he is doing it.
There it is! A CEO told me once "the secret to success is to nail it the first time around"! I wish I could, every time!
Yes he's right nail it the first time but only in public after a series of private trials
Two legends. Thank for this stuff
I had been eagerly waiting for this episode. Thank you so much.
You're welcome 😊
I can see from this video how much respect Dave has to Kent as someone who has influenced our discipline and Dave itself. It feels like that overwhelmed Dave a bit...
But it is great to see 2 influencial people talk about important stuff for endeavour of software engineering. How their ideas are overlapping, even though they never talked in person before.
Agree with your insight. Dave seems nervous and is verbose and talking way too much. He should have a script of questions.
Hi Dave, it’s amazing that you can share with everybody these exchanges of reflections, analysis on the origins and meanings of software development with those who made and make our industry. Thanks a lot for your generosity.
My pleasure!
The Legend Kent Beck.
The OG. The GOAT.
I was pleased to hear him dispel this recent stuff about TDD being "nothing to do with testing", of course it is!
That was a great interview, Dave. Thank you very much for the effort!
Awesome chat between you two! Thanks for recording and sharing all this wisdom 🤙🧠🥳
I want this on a T-Shirt: Kent Beck: "Anything that looks like a legible, easily understood model has to be wrong because that's focused on what I already know."
My OCD going nuts. These two gentleman produce more knowledge then my manager think a team of 20 ppl can output in one month.
I have been eagerly awaiting this episode!
I hope you enjoyed it!
"Payer programming" on the intro text at 1:10 would be pair programming I suppose.
Sunday morning comic caption: "No, we do pear programming. Everything we touch goes pear-shaped."
Perl programming? Pare Programming? I'm sure that Dave will fix this soon.
I would pay those guys to pair program with me 😅
A pear with cables and a chip. You program it to walk and scare people.
Don't forget "Prayer Programming"!
Change code, cross fingers 🤞, refresh...
Love this. Absolutely love it.
So glad!
Thank you Dave
My pleasure!
“The difference between good design and bad design has much more to do with the relationships between the people involved than this system calling that system.” -Kent Beck
I would pay actual money to see Dave moderate a debate between Kent Beck and Rich Hickey.
Great talk
This is awesome! Any thoughts on releasing some of these videos as a podcast? Apologies if that's already been done or mentioned!
My biggest takeaway from those is to separate structural changes from behaviour changes when raising pull requests. Makes sense in hindsight, but the teams I've worked with have made tests in the same PRs as the code under test. It is much harder to review!
I’ve been applying that idea for a very long time now. It is a very natural thing to do once you have some experience. I tend never to mix behavioural changes to structural changes. If I noticed, for example, a typo, or I spot a function that needs implementation (not interface) refactoring, I do that in a following PR (to be done soon after the one with behavioural changes I’m working on). PRs, for me, must have a very limited scope.
Minute 11:12 is a great summary of Agile
I’m theory, iterative development doesn’t just apply to software, but also process change and information flow change. A company could try to completely design a new process and/or team hierarchy and replace the existing process in one fell swoop… but they would be better to improve iteratively. And like Dave always says, always test to verify the changes. The concept of TTD therefore and all the related refactoring techniques that apply to code, also apply to business transformation. That’s a pretty cool concept to think about! The assumption is that companies are just analog versions of software.
Read his book but never actually seen him in video before 😮
When you say design while you’re creating a test do you mean coming up with the objects you need during the process and hitting the shortcut to create them? This has been a gap that I’m not sure I’ve heard when it’s not just smoothed over - five years in development 🙏✌️
Legends have to technically be deceased but know what you mean. What great knowledge.
Had not heard of TCR! 💭
Good talk. Dave a bit starstruck😊
🤩
Oh yes! SMaller Steps better. Planning smaller, building smaller, testing smaller, deploying smaller. It makes it so much easier to manage the flow of delivery. In fact I feel like the biggest challenge for teams is work breakdown and not technical stuff about 80% of the time.
I am curious what you mean by breakdown.
Mind you, my experience has not been XP, or CI direct trunk development.
I've always found poorly defined functional goals as the primary barrier to development teams.
The basis of all engineering design involves breaking down high level processes into ever smaller levels okay you have things that can be built individually
Great talk.
Just one thing, if you deploy each 10m, you dont have enough data on customer behavior to see if your doing better or worse, unless your a mega used software
But your deployment's would also be equally small, so your changes would not be changes requiring monitoring customer response, at least not until after a few hours of work at least.
But you customers can start using those features straight away, even though feedback on those features comes a few hours/days later. The important thing is to always keep your system in a releasable state and optimise for complexity, so if anything needs changing, it can be quickly done.
There has to be some acknowledgement that engineering doesn't agile build bridges - they have a fairly rigid set of budget, location and outcome criteria.
Unfortunately software engineering is either assumed to be "engineering" or has to be funded in the same model.
I think most funding owners grossly over estimate the value and grossly underestimate the cost. So they "solve" the problem of variability in vale/cost but requiring more effort up front.
I think there is a place for initial waterfall to test the specification for organizations who don't use VC funding to robustly test the idea - the problem is pet/executive projects.....
Actually they do. When a bridge builder engineer have to build a regular bridge it is just following a process. They chose the style calculate the measurements and done. When they have to build a bridge which was never built before, at that when real engineering begins. They try out new structural configurations, run simulations and so on, but of course they do not do it on full scale.
The design and engineering of bridges is not as simple as outsiders tend to think it is.
From: en.wikipedia.org/wiki/Tacoma_Narrows_Bridge_(1940)
> "Following the incident, engineers took extra caution to incorporate aerodynamics into their designs, and wind tunnel testing of designs was eventually made mandatory.[43]"
The animated borders around each person in the video are very pretty, but my goodness they are quite distracting for me sometimes. They remind me of the time when screensavers used logos that bounce around their monitors and almost perfectly hit the corner.
TEst Driven Development is a process of building and designing one test at a time. Yes it has tests, but the issue isn't test, the issue is knowing what works up to the point of the last test written. To the degree that you can test it at that level anyways.
How do we do this around contracts in the consulting industry? I’m in the shadow of leadership as you said, but what’s some feedback there??
You don't. You absolutely don't. Stay in business by disregarding most of this advice. I'm not saying these are not good approaches, but they are at best partially applicable in a development as a service business model.
@@byronjones5902 completely disagree. The best handoff you can do as a contractor is that of an artifact documented and covered by a living specification, which is the test suite. It is part of the proof that you have delivered your work as specified, and it doesn't leave people cursing that you ever developed anything for them. The worst contractors are the ones with the bad habits. There's no reason that standards should be, or are, lower for contingent labor than for FTEs. TDD doesn't slow you down, either, if you are competent at it.
@@sciros I actually agree with that, specifically, that its great to leave behind a living spec. Problem is, the people cutting checks have a completely different viewpoint than the people writing code about its value. More often than not, those people value written documentation, but not the test suites that back up the claims made about the solution's functionality in said documentation -- particularly when the company soliciting contracting services is not in the tech space ("What the heck is this?", "Did we have to pay for this?", "The test-thingy you showed us says everything works.. so why I am having issue XYZ? If it doesn't ensure there will be no problems, why did we have to pay for it?"). I'm not anti-test, just pro money. With regard to TDD as a practice, I've learned that its a matter of how the individual developer's brain goes about problem solving. For some, its a performance boost -- for others, a hindrance.
@@byronjones5902 >people cutting checks have a completely different viewpoint than the people writing code about its value.
This is a lie that keeps been perpetuated by those who accuse developers of not understanding how business works, that clients "don't write blank checks", that clients require everything to be properly documented, etc. Lies. I (and others) have debunked those lies for years now.
I have worked on a significant number of projects/products for clients of consulting companies for years and never EVER come across what you describe.
People cutting checks need value in their hands and, as developers, we must be able to deliver that value. There are no different viewpoints. There are better and worse ways of working. Software must be developed with iteative and incremental approaches, continuously delivering valuable software into the hands of the customer, listening to feedback, adjusting. Repeat.
I freak out doing tcr. It always feels like what if I waste my effort. For now Im sticking to tdd
It would be great if this was available on spotify so I could listen with my screen off
🌟 🌟 🌟 🌟 🌟
Wonderful video. It's a shame that most people working in software still don't get it after decades. Do yourself a favor and read the books ...
IBM? Did Harlan Mills have anything to do with that?
Dave you seemed a bit impressed by interiewing the "legend" did you ? 😁
I'm like actually starstruck aye
OMG, Beck doesn’t even think one can use the word “old” unless one is oneself old!
The more things change, the more they stay the same.
Autocorrupt got Dave as well with "payer programing" at 1:10 :)
Hey Dave, I guess there should be a translation mistake , should be pair programming instead of payer programming
Yes, sorry this typo slipped through.
Nice talking!
I love "payer programming"
Holy crap its Walter White of software development 😂
Agile will not get you more lines of code out that door than waterfall, it will get the RIGHT lines of code out the door and start getting an roi sooner. If you need predictability, which most business contracts are written around, waterfall is likely the right answer.
I mostly agree, but not where you say "Waterfall gives you predictability", in my view it absolutely doesn't. It gives you the illusion of predictability, but it doesn't allow for integration costs, and always, in my experience, results in systems going into production with lots of bugs. But it doesn't schedule the time to fix those bugs. At that point the project goes into "Emergency Change Management" which is basically agile, but now with an enormous technical debt.
Waterfall has never been the answer. There is a common misunderstanding in the industry that Waterfall is a “model”. No one - and I mean *no one* - in the history of software engineering has ever presented a “Waterfall model”. The idea that software had to be developed in subsequent phases was adopted by the US DoD. They never understood that what Dr. Winston Royce was presenting in his 1970 paper on how to manage the development of large systems was a model *to avoid* (he wrote something along the lines of “don’t do it this way, it invites failures”) and proceeded to explain how to produce those systems iteratively. He even mentions involving the customer in a very similar way to what the Agile Manifesto describes. Royce himself was a supporter of iterative and incremental methods. The industry understood the opposite and a “Waterfall model” dominated it for 20 years, until the adaptive methods reemerged and Agile was formalised. We have always knows, however, that software should *never* be implemented with a “Waterfall model”.
Customers don’t need predictability. That’s an extremely common fallacy. Customers need a software that solves their problems. They only need predictability when needing predictability is the only option we give them. If you ask me for a software, and I tell you that you’re going to get it at some point in the far future, then of course you want to understand how long it’s going to take and how much it’s going to cost you, before you embark on a journey where you won’t see results for a long time. If, on the other hand, I agree with you to release limited-scope features continuously, frequently, so you can evaluate them, give feedback and adjust, limit your financial exposure, and decide, at each step, if you want to continue investing in the product or not, you are not going to need predictability. Remember: “Waterfall” was never a model for software development. We have known that software must be developed in iterative and incremental ways for 70 years now.
@@andrealaforgia 💯💯
@@andrealaforgia Call it what you will, but most contracts define what should be implemented, by when and with a known budget. In fact, they usually spell out exactly what happens when those things don't happen. Waterfall may not be the answer in this very common case, but agile definitely isn't either.
@@adambickford8720 If you are saying that a lot of companies implement a fixed scope + fixed budget + fixed time policy and they come up with hefty fees when you don’t deliver according to their fancy dreams, you are right, but that’s only because they have not yet understood the nature of software and insist on applying a model that DOES NOT work for software. The people demanding that way of working are the same that object to the (sensible) arguments against long-term estimates in software starting their sentences with “Well, if you build a house, you want to know…”.
Software is not houses.
Companies that adopt those contracts are not successful at delivering software. It’s proven by data. The 2015 CHAOS Report front the Standish Group collected data from the industry proving that Agile is 3x more successful than Waterfall and Waterfall is 2x more likely to fail, so yes, Agile is the right answer for software development. But, as I said, we already knew that.
There are a lot of different agile contracts that can be adopted to implement software agilely.
“Payer programming”?
Payer programming?
Oh, "Ken**t**".
Not "Ken".
Oof...
Payer programming 😂
At first glance I thought it was Prayer Programming😊
Dave talks more than the guest :/
Nearly always 😉
C3 a project from.chrysler company using smalltalk environment