On the shortness of feedback loops ➰

Image Source Wikipedia

• Born 1961
• American software engineer
• Creator of Extreme programming
• One of the 17 original signatories of the Agile Manifesto
• Leading proponent of Test Driven Development (TDD)
• Wrote SUnit, then co-wrote JUnit

This is Kent Beck, and above is a small résumé. But look at some of the words. They don't make you think about anything small. There is "extreme", then there is a "manifesto", and don't get me started on "unit testing"! (because they take so much time to write 😉).

I'm kidding. Mr. Beck is a hero to me. He has been a mentor to me and many others, through his work, his writings, and his public speaking. The practices that he discovered, have radically changed the field of software development. But more than that, I love the way he has allowed himself to evolve through the years. It is because he is open to discussions - even if they are opposing ideas. He is honest, fair, and practices empathy. You can say that it is because he hasn't stopped exploring, re-evaluating, and testing his philosophy. This is true because of the core principle that he believes in.

as an engineer, you should constantly work to make your feedback loops shorter in time and/or wider in scope

— Kent Beck (@KentBeck) November 11, 2014

If you listen to his interviews, it is a common theme with him. Getting feedback, making it cheaper to do so, measuring it, and making changes before repeating the cycle. Let's see how it reflects in his work.

Mr. Beck wasn't the only one who came up with radical changes in the mid-90s¹, but he was one of them. He discovered and practiced "Extreme Programming". You might look at the below diagram and say that for most of us, this is a normal thing at work. Back then, it wasn't. The world was still struggling to make a move in the tar pit that is the waterfall model. It took years to release something, months to develop and test it.

Image source Wikipedia

You see how all the stages are made shorter - releases, development iterations, tests. All these are nothing but feedback loops.

• Release a feature, and you get feedback from customers, monitoring systems, and your hardware.
• Deploy it in the test environment, you get feedback from testers.
• Run your unit tests, feedback in seconds!
• Pairing - live feedback!!

Why is XP not more popular today? Three reasons according to me

• Mr. Beck is not a good marketeer. Most people would have been simply intimidated by the word extreme.
• Its cousin went the certification route and became more popular. Proabably, since a certificate is something that people would find more trustworthy.
• XP mandates a set of engineering practices like pair programming and in XP the teams can have dynamic timelines and mutable backlogs which are mostly driven by the customer. So basically, it is more dynamic and needs more from you emotionallly, as needs a lot more interaction with people.

Mr. Beck says that he rediscovered, and not discovered Test-Driven Development (TDD). He hints at where he got it from below.

The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output.

May 2012, Kent Beck on Quora, answering the question - Why does Kent Beck refer to the "rediscovery" of test-driven development?

Below is a simplified version of one pathway that may occur during TDD.

• Create a feedback loop by writing a failing test. Write just enough to make it fail
• Execute it and watch it fail
• Write just enough code to make it pass. Watch the test, hoping that it goes from fail to pass 🔴➡🟢.

How can TDD become addictive? Your brain gets a small dopamine shot each time you anticipate, then succeed. You try it again and again and your brain feels it, again. Over a period, you form a habit. Your brain begins to crave to make tests pass again. So, you look for new expectations, to make them fail.

TDD also makes you used to the safety net of the tests that you've written so far. You have built a living specification for your code which automatically checks for validity every time you make a change to the behavior. While the latter is the most advertised benefit of TDD, it is the addiction that gets you hooked.

Mr. Beck points out a third reason for TDD. We tend to forget that programming is inherently hard. When writing software, people mostly struggle with the unknown and going through emotionally dark places that make you lose belief in yourself, and then suddenly, Bam! You discover a solution. With TDD, you just write down expectations one at a time in small increments and add just enough changes in your code to fulfill it, and it almost surely leads you to your solution. With lesser mental trauma.

People tend to avoid TDD. It is a mindset change, and there is a great amount of resistance when you ask someone to pick it up. There are many reasons for it. No good motivators, not having a good setup, and the most popular reason is that, you think we can work without it. This post is not trying to convert you into a TDD practitioner for life. I want you to (re)look at it as creating a feedback loop for yourself while you are programming. Another addition to your toolbox for when you are in the dark, looking for an answer.

There are opposing opinions about how TDD does not apply to all forms of development. Some might say that TDD may harm the design of your software. I'd say, in most cases unless you see the ill effects, TDD is a good first choice. I recommend that you watch Is TDD Dead?, where Kent Beck invites David Heinemeier Hansson, the creator of Ruby on Rails on Google Hangouts for a debate on TDD. Pretty cool isn't it?.

Mr. Beck, himself doesn't advocate for TDD every case too. But what he doesn't let go off is the need for a feedback loop.

Sometimes, but not as often as I did before joining Facebook. Going back to first principles, I am responsible for the quality of my work. The only way to check the quality of my work is with feedback. Some of that feedback can be collected before going into production and some can only be collected in production (this was a point I didn't understand four years ago). For the feedback that can be collected before going into production, tests are one way of generating that feedback (tests can be ruinously expensive to write and/or maintain if your system isn't designed for them). When I do write tests, I nearly always write them TDD-style (one at a time, before coding).

-- November 2014, Kent Beck on Quora, answering the question - Does Kent Beck use TDD at Facebook? How?

TDD or not, you can ask the system to your life or your professional life. See the systems that you use and the once that depend on you. Are they giving you feedback frequently? Is it cheap to get? Can you measure it? Does it help you identify changes to make? Something to ruminate about over the long weekend.

~ ▪ ~ 🪔🪔🪔🪔 ~ ▪ ~

🏮 Have a safe and happy Diwali! 🏮

For more fun posts like these, click here to see a list of all my posts