Mob and pair programming are meant to ease collaboration and improve communication between team members. Still, other aspects of software development can also gain something from it.
This is the case for testing optimization, as well as for preserving an organization’s culture and growing teams. To shed light on these topics, we interviewed Llewellyn Falco, agile coach and the creator of ApprovalTests.
Read the edited transcript or listen to the full episode.
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Introduction
In this episode, Darko interviews Llewellyn Falco, agile coach and the person behind ApprovalTests. ApprovalTests is a software tool for simplifying the implementation of unit testing asserts and improving developer teams’ overall testing workflow.
Unit testing consists of testing applications through their smallest testable components (units) by setting a single test into each one of them. Asserts, in turn, are in charge of checking if a given test result matches its expected result.
The inspiration for ApprovalTests came from Llewellyn’s experience with the Windows’ command-line launcher SlickRun:
“SlickRun introduced me to this idea that there is a lot of power not in doing things yourself, but just in harnessing the power of other applications.”
-Llewellyn Falco
ApprovalTests makes the unit testing asserting process go underground: it sits underneath the testing framework, and when asked to verify the path, it takes a snapshot of it and turns it into an output file. The first time ApprovalTests is used, it will launch a fail report, since it needs to be told that the result is what the user expects.
After the user approves these results, ApprovalTests will stay in the background. In case ApprovalTests finds a mismatch, it will pop up and show the differences in the code. It is up to the user to either fix the differences or, if the results show what the user expects now from the code, approve them.
Llewellyn understands that “the whole point of an automated test is that it doesn’t bug you when stuff works.” As such, ApprovalTests simplifies testing because it doesn’t notify the user unless it finds mismatches that need their attention.
What does good and bad testing look like?
Llewellyn regards bad testing as a matter of misinterpretation. Tests are not for checking if something works, but a way for programmers to track their work and ensure it’s moving in the right direction.
When code changes, the fact that tests find this as a mismatch doesn’t mean they are mistaken. “Often we inadvertently lock the implementation instead of the result.” He says. “It’s like I’m getting the right result, but my tests are breaking. Now my tests are hurting me.
That’s the opposite of what tests are supposed to do. So making it very easy to be like, “No, what I want to do has now changed.” Let me just hit a button and say, “Yes, this new stuff is actually what I want.” That’s powerful.”
Listen also: Lisa Crispin: Holistic Approach to Testing
In this same regard, Llewellyn sees test failure as an indicator that code is currently under work. It is only when tests fail that code has changed, hence, it’s under work; in case tests aren’t failing, it probably means that the code hasn’t been touched.
On the other hand, to Llewellyn, tests can end up piling up and adding disproportionate time to feedback loops, especially in continuous testing. In software development, feedback loops are a way of validating processes and getting feedback to continue improving the code. Continuous testing, for its part, is the practice of preserving application testing during the whole life cycle of the application.
To avoid these scenarios in which compiling takes too much time, Llewellyn proposes, for one thing, cleaning the code built over the years in a proper time frame instead of expecting to be able to clean it in a matter of days.
At the same time, he encourages mob programming as a way of preventing large waiting times for compilation:
“So a lot of times the pain of waiting, if it’s individual, you’re annoyed with it, but it’s just the way it is. When you get this together in a group, you’re like, “Oh my God, this sucks so much.”
-Llewellyn Falco
I mean five people are sitting around waiting for a compilation or a test run that takes 10 minutes. That is so much more painful than when you do it.
Because when you do it, you’re like, “Okay, well I’ll open up my email. I’ll surf Reddit. It’s compiling. I’ve got time to play.” But when you’re doing it in a group, that pain becomes very noticeable.”
Going slow: the importance of incremental change and growth for teams
When coaching developer teams, Llewellyn understands that people shouldn’t be forced to do something new. Instead, he thinks they should start with what they feel comfortable doing at the present time until they are willing to try new things to move forward incrementally in the direction he wants:
“Oh, they’re not ready to write tests, but they are ready to start extracting methods, well then let’s just extract a method. Or if they’re willing to write tests, but all their tests are long, maybe I can make them a little bit shorter. Or we’re deploying every four weeks.
I want them to get to one day, but maybe I can get them to three weeks, deploying every three weeks. And then when that’s done, I can get them to deploy every two weeks. And then when that’s done, I can talk about it every week.”
-Llewellyn Falco
For Llewellyn, patience is important for training developers and enlarging teams. Therefore, Llewellyn believes teams need to grow slowly and is against the idea that more people results in a more productive and lucrative company.
Listen also: Justin Searls: How to Grow Your Engineering Team Tenfold in a Year and Keep Test Suites Healthy
What’s more, Llewellyn understands that when teams act as a single entity their productivity multiplies. As communication becomes inevitable the number of ideas and their sharing between its members boosts:
“With six people, six people who can talk to five other people, it’s 30 connections. It’s crazy. And very quickly these numbers just become logarithmically high.”
-Llewellyn Falco
Correspondingly, Llewellyn created a variation for pair programming known as strong-style pairing. In this type of programming, one person is behind the keyboard doing the typing, while the other is in charge of the thinking.
The idea behind this practice is to engage participants with one another and improve their communication for achieving a common goal.
Listen also: Agile Coaching and the Samman Method with Emily Bache
Further, Llewellyn measures his impact on teams by looking not at what he can do to improve teams when working alongside them but what they can continue to do once he isn’t with them anymore.
He wants companies to internalize his teachings long term, so first, he goes back months later to know if they continue to apply his teachings, and again a year or year and a half later to learn what things they have figured out on their own:
“I have a saying of if the code you wrote last year doesn’t embarrass you, what have you learned?”
-Llewellyn Falco
Llewellyn prefers developers to organize into small teams, or at least teams that have grown slow. He sees companies hiring massively as wasting money, doubting that increasing the number of developers hardly equals more productivity.
He believes that with a larger number of team members, and consequently more meetings, decision-making takes a hit:
“Sometimes planning to do something can give you the same dopamine rush of accomplishment of actually doing it, which is another dangerous part of the way human brains work.”
-Llewellyn Falco
In like manner, Llewellyn understands programmers are not as valuable for companies that have grown too fast:
“if you can just randomly fire 15 people, there’s something wrong with how you’re paying attention to people. Ah, you grew too fast. You shouldn’t have 15% that you can cut. And B, when people do that, they lose a lot of the best 15% of their company. […] voluntary people who are like, “Well, I’m good. I can get another job. Let me get out of here. So you lose a lot of really good people.”
-Llewellyn Falco
For keeping teams small, Llewellyn emphasizes organizing as mobs. In this way, a team acts as a unit instead of as a set of different entities.
Likewise, Llewellyn is in favor of mob programming as a way of maintaining direct communication to develop and resolve product issues. More importantly, he sees mob and pair programming as the correct way for teams to grow slower.
It is by mob and pair programming that the culture of a team can spread successfully. Hence, As new people arrive with their own culture, Llewellyn recommends “have them adopt a new culture and then grow again so you can keep that culture”.
The bottom line
While Llewellyn isn’t still in an active role, he co-founded with Lynn Langit a charity known as “Teaching Kids Programming“. To defend the importance of children learning to program, Llewellyn weights this competence as vital for the world they are to live in:
“whether you’re a programmer or not, you will need to be able to understand how to create technology […] it’s like not everyone needs to be a programmer in the same way as not everyone needs to be an author, but everyone needs to know how to read and write, and coding right now is part of reading and writing.”
-Llewellyn Falco
He also recommends the aforementioned strong-style pairing programming for children to incorporate programming concepts as they type. Visit teachingkidsprogramming.org to learn more about this project.
Llewellyn has also uploaded many of his learning resources on his personal Github.
