I am convinced that the world needs more technical coaches. Practices like Refactoring and Test-Driven Development don’t just happen by themselves. It takes quite an investment in time and effort for most developers to see the point, and to realize how much it would help them to work this way. Then they need to put in some time and effort to become proficient using these skills, and a supportive team culture is essential. Having an experienced technical coach on hand can make all the difference for success.
During 2021 one of the teams I coached was struggling to make progress in a large, complex codebase. We worked together in an ensemble which enabled them to pool their knowledge and get a grip on the code faster than before. We held several learning hours focused on test design which helped them to improve the unit tests and get better feedback on their changes. Everyone said afterwards they felt like working with the coach had helped them to work more effectively. I’d like more teams to experience this kind of progress.
Samman is the method I use when I’m coaching software development teams. The two basic components are ensemble working – where you gather the whole team to work together on one programming task – and learning hours – where developers learn new skills and practice on exercises.
I published my book “Technical Agile Coaching with the Samman method” in January 2021, because I wanted to help other technical coaches to use this coaching method and to promote agile ways of working. When I held this book in my hand for the first time it was somehow larger and heavier than I expected. I felt a huge sense of accomplishment! Since then, I’ve more and more realized the book was just the beginning. There are a lot of development teams out there and only a few technical coaches who really know how to help them.
The book generated quite a bit of interest and I’ve spent a large part of last year talking and writing even more. I was asked to contribute articles about Samman coaching for some of the biggest online magazines in our industry – Methods and Tools and InfoQ. I also had a steady stream of invitations to appear on podcasts. I just went through and counted them – eight were published in 2021! (I list them at the end of this article)
I was invited to give the keynote address to the ACCU conference. It’s always a huge honour to give a keynote and I spent many hours preparing this talk. For the second time in my career I was also invited to speak at the annual Agile conference organized by the Agile Alliance. It’s one of the biggest conferences in the software world – also a great honour to be asked to speak there.
For most of my career I’ve been part of the Agile, XP, DevOps, Testing, Python and Java communities within software development. Although I have previously done a fair amount of architecture work, this year I feel I also took a step into the Architecture community for the first time. I was invited by O’Reilly to be a judge in their Architectural Katas competitions. I see technical coaching as one aspect of the kind of technical leadership that architects usually bring in an organization. Through this competition, architects from all kinds of organizations can practice their skills and learn from each other. I’m really happy to have been involved.
Looking forward to 2022, I’m anticipating another year of hard work doing technical coaching with teams, but also more and more training others to do coaching. I’m getting a lot of enquiries from organizations who see a need for better technical practices. My colleagues and I have only so much time available to coach teams, so I usually suggest pair-coaching with people already in the organization. Most organizations already have architects and technical leaders and often those people would like to learn to coach teams using the Samman method. It’s for that reason that we’re ramping up the train-the-trainer programme offered by ProAgile. We have new courses on Ensemble Working and also on Learning Hour Design, two of the key activities for a technical coach using the Samman method.
I remain convinced that good technical coaching is essential for building up productive and happy development teams. I look forward to continuing to spread better ways of working and coding together with lots of great people in 2022. Happy new year!
Podcast appearances 2021:
DevOps Sauna – a lovely chat with Sofus Albertsen, a former colleague of mine.
It’s Test-Driven Development with a twist! Developing new functionality with approval tests requires some slightly different steps, but if you’re a visual thinker like me you might just prefer it. In this blog post I’ll explain how it works.
You may be familiar with the Gilded Rose Kata. It’s the most popular exercise I have on my GitHub page. About a year ago I posted some videos demonstrating a way to solve it. I used several techniques, including ‘Approval’ testing, which is also known as ‘Golden Master’ testing. It’s an approach that’s often used to get legacy code under control. What’s perhaps less known is that you can use the same tools for new development. I’ve put together a new exercise – the ‘Lift’ kata – to help people understand how this works.
If you’ve never done the Lift Kata now might be a good time to try it out. I originally worked from this description of it, and I now have my own description and GitHub repo for those who want to try it out “approval testing style”. The first step towards solving it is to spend some time understanding the problem. I’m going to assume that most of you have been in a lift at some point, so take a few minutes to note down your understanding of how they work, and the rules that govern them. Perhaps even formulate some test cases.
I did this by sketching out some scenarios. I say ‘sketch’ and not ‘formulate’ quite deliberately! The way my mind works is quite visual, so for me it made sense to represent each floor vertically on the page, and write the name of the lift next to the floor it was on. This shows a lift system with four floors named 0, 1, 2, 3, and one lift named ‘A’, on floor 0:
This is just a snapshot of a moment in time. I then started to think about how a lift responds to people pressing the floor buttons inside. I figured that this is an important aspect to test and proceeded to sketch it out. It occurred to me that I could write a list of requested floor numbers next to the lift name, but then I noticed it was even clearer if I put a mark next to each requested. For example, if passengers request floors 2 and 3 I can sketch it like this:
The next move for this lift would be to go to floor 2 since it’s the closest requested floor. That example could be formulated as a test case sketch like this:
I can use this sketch as the first test case for TDD. I’ll need to write code for a lift with floors and requests. I’ll also need to write a ‘Printer’ that can turn a lift object into some output that looks like my sketch. I write some code for this and use the printer output in the ‘verify’ step of the test. After some work the output looks like this:
This ascii-art looks much the same as my sketch. One difference is that I wrote the floor numbers at both ends of each line. This is a trick to stop my editor from deleting what it thinks is irrelevant trailing whitespace at the ends of lines! I think it looks enough like my sketch to approve the output and store it as a ‘golden master’ for this scenario. Actually, I’ve already approved it several times as it started to look more and more like my sketch. And every time I did that I could refactor a little before adding more functionality and updating the approved file again.
I’m looking at the requirements again and realize that I haven’t modelled the lift’s doors. You can’t fulfill a request until you’ve opened the doors, and that only happens after you’ve moved to the right floor. I drew a new sketch including them, shown below. I’ve written [A] for a lift called ‘A’ with closed doors, and ]A[ for when it has open doors. I also show an intermediate step when the lift is on the correct floor, but since the doors are closed the request is still active:
To get this to pass I’ll need to update all of my lift class, my printer, and my test case. After a little coding, and a few iterations of improving both the code and the printer, the test produces output that looks like this and I approve it:
Now that the test is passing, I’m fairly happy that my lift can answer requests. The next feature I was thinking about was being able to call the lift from another floor. For this I think I’ll need a new test case. Let’s say I’m standing on the third floor and the lift is on floor 1, and I press the button to go down. I can include that in my sketch by putting a ”v” next to the floor I’m on. The whole scenario might play out like this:
As before, I spend time improving both the lift code and the printer. I approve intermediate results several times and do several refactorings. At some point the output from my program looks like my sketch and I approve it:
Great stuff! My lift can now fulfill requests from passengers and answer calls from another floor. Time for a celebratory cup of tea!
I’ve shown you the first couple of test cases, but there are of course plenty more features I could implement. A system with more than one lift for a start. Plus, the lift should alert the person waiting when it arrives by making a ‘ding’ when it opens the doors. I feel my lifts would be vastly improved if they said ding! I’ll have to come up with a new sketch that includes this feature. For the moment, let’s pause and reflect on the development process I’ve used so far.
Comparing Approval Testing with ordinary TDD
If I’d been doing ordinary Test-Driven Development with unit tests I might have created a dozen tests in the same time period for the same functionality. With Approval Testing I’ve still been working incrementally and iteratively and refactoring just as frequently. I only have two test cases though. The size of the unit being tested is a little larger than with ordinary TDD, but the feedback cycle is similarly short.
Having a slightly larger unit for testing can be an advantage or a disadvantage, depending on how you view it. When the chunk of code being tested is larger, and the test uses a fairly narrow interface to access that code, it constrains the design less than it would if you instead had many finer grained tests for lower level interfaces. That means the tests don’t influence the design as strongly, and don’t need to be changed as often when you refactor.
Another difference is that I’ve invested some effort in building code that can print a lift system as an ASCII artwork, which is reused in all my tests. In classic TDD I’d have had to write assertion code that would have been different in every test.
Try it for yourself
What I’ve done isn’t exactly the same as ordinary TDD, but I think it’s a useful approach with many of the same benefits. I’ve put this exercise up on GitHub, so you can try it out for yourself. I’ve included the code for my printer so you don’t have to spend a lot of time setting that up, and can get on with developing your lift functionality. I’ve also recorded a video together with Adrian Bolboaca where I explain how the exercise works. So far I’ve translated the starting code into Java, C# and Python, and some friends have done a C++ version. (Do send me a pull request if you translate it to your favourite language.) And that’s it! You’ve seen how easy it is, so why don’t you have a try at Approval testing-style TDD for yourself?
Posted by Emily Bache on 2020-04-24 at 09:34 under Code Kata. Tags: BDD, Code Kata, TDD Comments Off on How to develop new features with Approval Testing Illustrated with the Lift Kata.
How your team actually writes its code is very important if your organization is trying to build products in an Agile way. This post considers the risks associated with insufficiently Agile coding practices and explains how to identify them before they become major issues.
Nearly every software organization has high ambitions for increasing their agility and yours is probably one of them. It’s common to bring in experienced coaches to help teams operate with more agility and to discover ways of delivering more value. But, if you’re working on software products, you’ll find it’s hard to realize some of the benefits of Agile without changing the behaviour of developers in the codebase. Too many coaching efforts place little or no emphasis there.
Agile Coaching helps your business to become more successful by improving the way you plan and deliver software. Technical Agile Coaching specifically focuses on how people write code. How do you know if you need Technical Agile Coaching? Here are three signs.
You spend more time fixing bugs than building new features
Look at all the tasks you work on each week. Ask yourself how much time is being spent on innovative new features, and how much on fixing defects in existing features? For some teams the answer can be as little as 5% of time spent on proactive new work. Now ask yourself – how much more money would our organization make if we spent less time on fixes and more on delivering new features?
Turning this situation around is about increasing the quality of your work so that fewer fixes are needed, resulting in more time for innovation. Often, the root cause of defects is technical debt and code that is hard to understand and change.
You can mitigate against this by training your developers to build in quality from the start. Technical Agile Coaching helps teams to improve automated tests and reduce technical debt by demonstrating various techniques and practices for evolving design safely.
Delivery of new features is delayed, sometimes more than once
Are your new features around 80% done for long periods and then take forever to be actually ready for release? Often this is the biggest complaint from customers and other stakeholders. How much would it be worth to your organization for new functionality to be available reliably and on time?
Late deliveries are often caused by developers not collaborating effectively in the code. To build a new feature they need to bring the whole team’s expertise to bear, and integrate their work seamlessly. Typically, the coding work is not divided up in a way that makes collaboration easy, and changes are not integrated until late in the process.
Technical Agile Coaching helps developers to deliver on time: reliable automated regression tests promote better collaboration with a shared view of the current status; teams learn to divide up the coding work and integrate changes far more frequently than the interval between external deliveries; developers learn to use their tools better and to communicate effectively within the team so they can complete tasks more reliably.
Developers complain the code is so bad they need to re-write the whole thing
Sometimes developers ask for a hiatus in new feature development for several months, even a year, so they can start over by rebuilding the same functionality using new tools and frameworks. This is a significant cost to your business, and a large risk. A more staged approach carries far less risk and allows you to build better functionality with much more manageable cost.
Usually, an organization arrives in this situation after many years of accumulated technical debt. The technologies chosen originally become outdated and are not upgraded in a timely way. Developers make design decisions and then leave without fully documenting or otherwise transferring design knowledge to new team members. New features are added that were not anticipated in the original design. Gradually the code quality declines and it becomes harder and harder to work with.
Technical Agile Coaching helps developers gain better control over existing code, so they can continue working with it and building new features. Teams learn to migrate code to newer technologies in a series of smaller, less risky steps, adding new functionality as they go. Developers learn to pay off technical debt and to communicate better about design decisions.
Benefits of Technical Agile Coaching
Technical Agile Coaching helps developers to change the way they work, day to day, minute by minute, in their codebase. They learn to increase the quality of the code in their product and work more effectively as a team. The coach works closely with the developers while they are writing code to remind, reinforce, teach, and demonstrate Agile practices. With Technical Agile Coaching you should expect to see the following benefits:
Reductions in technical debt
Better automated regression tests
Improved communication between developers within the team
Smaller, safer changes integrated often and documented well
Improved effectiveness using team development tools and IDEs.
Technical Agile Coaching helps a team to improve how they write code, and begin to use more effective agile development practices together.
If you’re interested in getting some Technical Agile Coaching, please contact us at ProAgile. We have many coaches with a lot of experience in agile development and several with technical coaching expertise.
Note: this article was originally published on ProAgile’s blog
I only recently joined ProAgile and I feel we’ve got off to a great start. Last week my colleague Fredrik Wendt and I facilitated and hosted a Code Retreat event for a diverse group of software crafters from local companies.
at the start of the day
It’s the 10th anniversary of the “Global Day of Code Retreat” event and there were over 150 locations around the globe holding one last week. It’s not the first time I’ve facilitated a Code Retreat but it is the first time I’ve done one in Gothenburg, (the others have been in Stockholm). This year Fredrik and I were keen to bring together some local people, and contribute to the community here. ProAgile has recently invested in a fantastic venue for courses and training at our offices, and we want to take full advantage of it.
We contacted several local companies and specifically invited them to advertise on the event sign up page that they were going to send people. We were delighted when Boeing (Jeppesen), Pagero, Meltwater, Spotify and Greenbyte all agreed to this. Their intention to participate I’m sure helped get the attention of other local software crafters when we put out a general invitation with open sign-ups.
In the end we were a very diverse group drawn from many local companies both large and small. We had a game designer who favoured C++, a Scala enthusiast, a Kotlin proponent, a Python trainer, several Javascript developers, a self-taught PHP and Python developer, a CEO who still codes occasionally, and many local Java, Python and C# developers. Everyone got to pair program with people from other language communities and backgrounds.
Fredrik and I decided to hold a standard code retreat event and based our planning on this article: “Structure of a Code Retreat”. We held 5 sessions working on the “Game of Life” Code Kata through the day. In each session, people work in pairs starting from an empty editor, and come up with a new solution to the problem. Between each session you hold a short retrospective with your pairing partner before taking a short break and switching to a different pairing partner.
pair programming
In the morning sessions the focus is on getting to know the problem. We all try to find a good way to use Test-Driven Development and simple design rules to get a clean, understandable, flexible design. The sessions after lunch are about using this Game of Life exercise as a vehicle for trying out something new or otherwise challenging. We had some pairs using unfamiliar programming languages and environments. Some pairs were following strict design rules like ‘no if statements, no loops’ and ‘no function longer than 1 line’. Some people accepted the challenge to work on the problem as a mob; we were 4-6 people using one computer with me facilitating.
mob programming
Throughout the day there were opportunities to reflect on the way we write code: how design guidelines and programming languages and Test-Driven Development and personal preferences all interact to influence the code we end up with. In normal project work with deadlines and tricky business rules and security constraints and so on, you might not get much time to consider the fundamentals of what good software design looks like. Test-Driven Development is a complex skill to learn – it has many facets. I think all programmers benefit from taking some time occasionally to work on practice exercises and discuss software design principles with peers.
At the end of the day we reflected all together in a closing circle. Everyone had the opportunity to say a few words to the group about what they were taking away with them. When you’ve spent time working on a Code Kata, I think there is a complexity gap you need to bridge – you want to carry over the principles and skills you gained from that simple exercise to your actual production code situation. It’s useful to think about what you’ve learnt and explain how you want to apply it later.
In the closing circle, I was happy to hear several positive comments about Test-Driven Development and an intention to use it more. Some people had seen a new programming language and had ideas about when it could be useful to them. Several people mentioned they appreciated the chance to program with people outside of their company and comfort zone. It was a good day, and I don’t think it will be the last such event we hold in Gothenburg.
If you’d like to know about the next events hosted by ProAgile, take a look at our course calendar, keep an eye on ProAgile’s social media channels and perhaps join one of our networking groups.
whole group at the end
Posted by Emily Bache on 2020-01-27 at 09:16 under Coding Skills. Tags: Code Kata, TDD Comments Off on Global Day of Code Retreat 2019 at ProAgile.
Note: this article was first published on Praqma’s blog
Writing tests for ‘Theatrical Players’
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Martin Fowler recently published a new edition of his classic book ‘Refactoring’. The first chapter is a worked example of how he would go about refactoring a small piece of code that he needs to update with some new functionality.
This is a really common scenario faced by software developers daily. It’s impossible to anticipate every future change and enhancement, so the design of the code will often not be extensible in the direction you need to take it. Refactoring the design in order to make a proposed update easier is an essential skill.
I like using small exercises to practice these kinds of skills, called ‘Code Katas’. I’ve got a whole collection of them in my book ‘The Coding Dojo Handbook’, and more on my github page. When I saw Fowler’s example I felt it would make a really good kata. The particular refactoring techniques he demonstrates are techniques that many developers would benefit from learning and practicing.
I asked Fowler for permission to use his code, which he kindly granted, then I set about transforming this example into a kata.
Creating a new Code Kata
This is Fowler’s example javascript code, which produces a statement for a customer. The new functionality that’s needed is to produce the same information but formatted as HTML.
statement.js
function statement (invoice, plays) {
let totalAmount = 0;
let volumeCredits = 0;
let result = `Statement for ${invoice.customer}\n`;
const format = new Intl.NumberFormat("en-US",
{ style: "currency", currency: "USD",
minimumFractionDigits: 2 }).format;
for (let perf of invoice.performances) {
const play = plays[perf.playID];
let thisAmount = 0;
switch (play.type) {
case "tragedy":
thisAmount = 40000;
if (perf.audience > 30) {
thisAmount += 1000 * (perf.audience - 30);
}
break;
case "comedy":
thisAmount = 30000;
if (perf.audience > 20) {
thisAmount += 10000 + 500 * (perf.audience - 20);
}
thisAmount += 300 * perf.audience;
break;
default:
throw new Error(`unknown type: ${play.type}`);
}
// add volume credits
volumeCredits += Math.max(perf.audience - 30, 0);
// add extra credit for every ten comedy attendees
if ("comedy" === play.type) volumeCredits += Math.floor(perf.audience / 5);
// print line for this order
result += ` ${play.name}: ${format(thisAmount/100)} (${perf.audience} seats)\n`;
totalAmount += thisAmount;
}
result += `Amount owed is ${format(totalAmount/100)}\n`;
result += `You earned ${volumeCredits} credits\n`;
return result;
}
As you can see, the logic for formatting the statement is all mixed up with the calculation logic, so as it stands it’s not straightforward to add the HTML formatting feature. What’s needed is to change the design and detangle the logic, via refactoring.
Fowler mentions that the first step in refactoring is always the same – to ensure you have a solid set of tests for that section of code.
However, he did not include the test code he used in the book. (It’s a book primarily about refactoring, and I guess including test code would have taken attention away from that topic). To make this example into a Kata, I wanted to include some tests.
The testing approach I favour in this kind of situation is approval testing. The code exists already and it works, so the easiest way to add a regression test is to find some test data, exercise the code, and approve the result.
This is different from a test-driven development approach where you define the test case before the code exists. (You can use approval testing in that kind of scenario too, but that’s a topic for another article). I usually find it much quicker and easier to add an approval test to existing code than a classic assertion-based test case.
Creating a first approval test
Fowler supplies us with some test data – a sample invoice:
The function that we want to test, statement, returns the information to send to the customer, formatted as a plain text string. This statement string is perfect to use as the approved value in the approval test.
This is the test case I designed, it uses the Jest testing framework:
First, I read both data files and parse them into javascript objects. Then I call the function we want to test – “statement” and store the result in the ‘statement_string’ constant. The last line of the test checks that this result matches the approved value. What it does is compare the actual value against a stored value which I checked and approved earlier.
This is kept in another file:
__snapshots__/statement.test.js.snap
exports[`example statement 1`] = `
"Statement for BigCo
Hamlet: $650.00 (55 seats)
As You Like It: $580.00 (35 seats)
Othello: $500.00 (40 seats)
Amount owed is $1,730.00
You earned 47 credits
"
`;
Is it called Snapshot or Approval testing?
The Jest testing framework calls the approved value a ‘snapshot’. I prefer to talk about ‘approval’ testing and comparing with an ‘approved’ value. I think these words get to the heart of what you’re doing – deciding what is good enough to test against.
‘Snapshot’ as a word just implies it will be updated again soon. I like to emphasize the human agency involved in inspecting and deciding whether to approve a new value or not.
Is this test good enough to support refactoring?
This test goes a long way to giving us the confidence we need to start refactoring the ‘statement’ code. It generates a full statement with test data that seems realistic enough for this context.
I think it’s a good idea to do a little more analysis of whether this test is sufficient to support the refactoring we want to do. One way to do that is to run the test and measure code coverage. Lines of code that are not covered could be refactored away, or have bugs inserted into them, without the tests failing.
The coverage data shows only one line of code which is not covered by this test:
Line 28 in statement.js:
throw new Error(`unknown type: ${play.type}`);
Our test case is pretty good, to only have one line uncovered. The test data supplied by Fowler includes different kinds of play that already exercise several paths through the code.
This code path is different, however. If you end up on this line then the function aborts, and doesn’t produce a statement. We can’t tweak the data in our existing code to make it also execute this line and still produce a statement.
What we need is an additional test, one that uses an unsupported play type. I invented some new data that continues the Theatrical theme:
statement.test.js
test('statement with new play types', () => {
const invoice = JSON.parse(fs.readFileSync('test/invoice_new_plays.json', 'utf8'));
const plays = JSON.parse(fs.readFileSync('test/new_plays.json', 'utf8'));
expect(() => {statement(invoice, plays)}).toThrow(/unknown type/);
});
This test is not an approval test, it’s a normal assertion-based test. It checks that the error is thrown and the message contains the string ‘unknown type’.
I could have instead used an approval test to check the error message. In this case I chose not to do that. The string to be checked is quite short, and there is little advantage in storing it in a separate file away from the test code.
Confidence in the tests
With that test added, we’re more confident we can use this test suite to support refactoring.
We have 100% coverage now, after all. Unfortunately, that is no guarantee that our tests are perfect, or even reasonably good. One thing I like to do is a spot of (manual) mutation testing. to assess how good my tests are.
I edit the code to insert a bug, then run my tests. If they fail, then that’s a good sign. I might try adding bugs in several different places to increase my confidence.
When I try it on this code, I find any change that affects the way the statement is presented gives me a failing test. I can also easily get a nice diff showing exactly what I broke.
I’m now feeling pretty confident these tests will be good enough to support refactoring.
This is a good starting point for the kata. From here you can practice all the refactorings demonstrated by Fowler in his book, with a safety net to alert you if you make a mistake.
When you come to implement the HTML rendering feature, it should be straightforward to add a new test for it too.
Adding more languages to your tests
In the book, the example language is Javascript, which is widely-used and understood. I often work with teams who also use languages like Java, C# and Python, and the refactoring techniques are just as relevant in those languages. Once I had this JavaScript version working, I added a translation or two. One of the reasons I keep my exercises publicly available on GitHub is so that people can send me pull requests.
If you’d like to do this exercise in a programming language that’s not supported yet, you can fix that for everyone 🙂 I particularly like getting pull requests with translations of my exercises.
The first chapter of ‘Refactoring’ containing a worked solution to this problem is available as a free sample. You have every opportunity to practice and learn these testing and refactoring techniques now.
Happy coding!
Posted by Emily Bache on 2019-11-08 at 14:00 under Code Kata. Tags: Code Kata, refactoring, TDD Comments Off on Turning an Example by Martin Fowler into a Refactoring Kata.
