Kent Beck On The FIRST Testing Frameworks, TDD, Waterfall & MORE | The Engineering Room Ep. 16

[@ContinuousDelivery]

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

[@detre3521]

The legend himself, Kent Beck.

[@rajadas6432]

Two legends in one frame. Absolute honor to listen to them. Thank you for teaching us.

[@pepijnkrijnsen4]

Dave Farley interviews Kent Beck. My day has been made. Thank you!

[@ApprendreSansNecessite]

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.

[@eloy4]

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!

[@Kenbomp]

Yes he's right nail it the first time but only in public after a series of private trials

[@shashank.c]

I had been eagerly waiting for this episode. Thank you so much.

[@ContinuousDelivery]

You're welcome 😊

[@alexandre8869]

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.

[@ContinuousDelivery]

My pleasure!

[@mcsee]

Two legends. Thank for this stuff

[@bleki_one]

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.

[@JosephButson]

Agree with your insight. Dave seems nervous and is verbose and talking way too much. He should have a script of questions.

[@erikipsen1682]

Everything you guys talk about is gold!

[@amitev]

That was a great interview, Dave. Thank you very much for the effort!

[@davemasters]

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!

[@fadidib8516]

The Legend Kent Beck.

[@petropzqi]

My OCD going nuts. These two gentleman produce more knowledge then my manager think a team of 20 ppl can output in one month.

[@BangsarRia]

Kent talks a lot about varying the order of lines of code. Uncle Bob formulated the Transformation Priority Premise to prioritize coding order in TDD; when he applied it to a sorting kata twice, using two slightly different orderings, the result was a different popular sorting algorithm each time (see the Clean Coder Blog).

[@manishm9478]

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!

[@andrealaforgia]

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.

[@BernardMcCarty]

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."

[@GrahamStrickland]

This is awesome! Any thoughts on releasing some of these videos as a podcast? Apologies if that's already been done or mentioned!

[@raticus79]

"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."

[@a.accioly]

Perl programming? Pare Programming? I'm sure that Dave will fix this soon.

[@EzequielBirman77]

I would pay those guys to pair program with me 😅

[@theodorealenas3171]

A pear with cables and a chip. You program it to walk and scare people.

[@JohnKerbaugh]

Don't forget "Prayer Programming"! Change code, cross fingers 🤞, refresh...

[@CodeLlama]

I have been eagerly awaiting this episode!

[@ContinuousDelivery]

I hope you enjoyed it!

[@CollegeCode]

“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

[@br3nto]

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.

[@OutOfDevOps]

Minute 11:12 is a great summary of Agile

[@Chemaclass]

Awesome chat between you two! Thanks for recording and sharing all this wisdom 🤙🧠🥳

[@7th_CAV_Trooper]

I would pay actual money to see Dave moderate a debate between Kent Beck and Rich Hickey.

[@bbry323]

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??

[@byronjones5902]

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.

[@sciros]

@@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.

[@byronjones5902]

@@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.

[@andrealaforgia7699]

@@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.

[@redpepper313]

8:10 Waterfall is the result of top management demanding evidence from their direct-reports that the project is under control who in turn demand the same evidence from their direct-reports in a cascading pattern all the way down the chain of command until the developers eventually cough up a 3-month projection so that everyone can relax… until the end of the quarter…

[@BangsarRia]

@41:48 Kent says we should be "exploring the space". Perhaps we programmers need more cowbell? I'm up for that

[@boomerau]

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.....

[@banatibor83]

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.

[@craigyoung8008]

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]"

[@Mancityfan50514]

Thank you Dave

[@ContinuousDelivery]

My pleasure!

[@Veretax]

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.

[@Veretax]

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.

[@JohnKerbaugh]

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.

[@Veretax]

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

[@BangsarRia]

The reason it works is the key difference between waterfall and agile and that is the frequency of feedback. In TDD and TCR the result of the test is the feedback. Kent makes it a lot clearer in his talks about the return of waterfall.

[@gmedia7041]

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

[@jarldue123]

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.

[@andrealaforgia]

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.

[@ryanvogel5895]

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.

[@bbry323]

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 🙏✌️

[@michaelutech4786]

Why does the guest get the small window? Strange setup...

[@daverooneyca]

Love this. Absolutely love it.

[@ContinuousDelivery]

So glad!

[@toopkarcher]

Read his book but never actually seen him in video before 😮

[@ismaelgrahms]

Great talk

[@BryonLape]

IBM? Did Harlan Mills have anything to do with that?

[@Kenbomp]

Legends have to technically be deceased but know what you mean. What great knowledge.

[@swagatochatterjee7104]

I freak out doing tcr. It always feels like what if I waste my effort. For now Im sticking to tdd

[@jamontino]

Good talk. Dave a bit starstruck😊

[@ContinuousDelivery]

🤩

[@bbry323]

Had not heard of TCR! 💭

[@justinrogo1415]

It would be great if this was available on spotify so I could listen with my screen off

[@gospelofchange]

53:35 "Software design is an exercise in human relationships"

[@gospelofchange]

54:00 "if the relationships are sick the software is sick"

[@samuelmv78]

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 ...

[@birames.1154]

Dave you seemed a bit impressed by interiewing the "legend" did you ? 😁

[@banatibor83]

Autocorrupt got Dave as well with "payer programing" at 1:10 :)

[@NickDanger3]

OMG, Beck doesn’t even think one can use the word “old” unless one is oneself old!

[@KurtiZv]

I'm like actually starstruck aye

[@BryonLape]

The more things change, the more they stay the same.

[@majucamex08]

Hey Dave, I guess there should be a translation mistake , should be pair programming instead of payer programming

[@ContinuousDelivery]

Yes, sorry this typo slipped through.

[@adambickford8720]

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.

[@ContinuousDelivery]

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.

[@andrealaforgia]

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.

[@ContinuousDelivery]

@@andrealaforgia 💯💯

[@adambickford8720]

​@@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.

[@andrealaforgia]

@@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.

[@brownhorsesoftware3605]

🌟 🌟 🌟 🌟 🌟

[@lateahc]

Maybe not Payer Programming, but Pair Programming? 😉

[@HadalSayer]

Holy crap its Walter White of software development 😂

[@alexreizer9249]

I love "payer programming"

[@davidherzlos2852]

Nice talking!

[@NickDanger3]

“Payer programming”?

[@m3rc14n]

Payer programming?

[@theodorealenas3171]

Oh, "Ken**t**". Not "Ken". Oof...

[@whiteF0x9091]

Dave talks more than the guest :/

[@ContinuousDelivery]

Nearly always 😉

[@StenAkselHeien]

Payer programming 😂

[@Mancityfan50514]

At first glance I thought it was Prayer Programming😊

[@Kenbomp]

C3 a project from.chrysler company using smalltalk environment