Llewellyn Falco

The single worst architectural anti-pattern is also the one I see the most often. It locks you into an architecture. Makes your choices permanent and inhibits being able to respond when you need to scale.

We are going to look at multiple examples of this anti-pattern. Not only focusing on how to avoid it in the first place, but also how to restructure code once you have detected it in your current system.

Let’s get back to basics.

One of the microskills often used in TDD is Consume First Architecture, which simply means using the fields and methods before they exist. Sounds easy? Well yes and no. Even simple lines of code can have HUGE implications on your architecture. The real skill in consume first is to be able to see, question and respond to those implications on sight.

In this lab, we are going to geek out over a single line of code. We will take it and turn it into 40-50 variations and explore how each variation impacts the resulting design.

In this guided demo, we are going to look at 3 different techniques that are remarkably powerful in combination to cut through legacy code without having to go through the bother of reading or understanding it.

The techniques are:

Combination Testing: to get 100% test coverage quickly

Code Coverage as guidance: to help us make decisions about inputs and deletion

Provable Refactorings: to help us change code without having to worry about it.

In combination, these 3 techniques can quickly make impossible tasks trivial.

Will will be doing this on the Gilded Rose Kata, https://github.com/emilybache/GildedRose-Refactoring-Kata

It is extra beneficial if you try it out yourself first so you can see how your implementation would differ.

“In order to make delicious food…. you need to develop a palate capable of discerning good and bad. Without good taste,
you can't make good food.” - Jiro Ono (World’s Best Sushi Chef)

Many of us are stuck with messy code. We know it’s not great but it works and what can we do? Where and how do you start?

We are going to use some cutting edge training to train your pattern recognition section of your brain to instantly recognize common, reoccurring anti-pattern (smells) in your code.

Then we will learn very specific techniques to start improving on these specific smells.

Once you are trained to see these anti-patterns you’ll recognize them everywhere. Now that you are equipped to handle them your code will start to transform into something beautiful and easy to work with.

Red - Green - (refactor)

We all know that refactoring is suppose to be the step that let’s us tease apart the logic of our code. ‘Fake it till you make it’ allows for us to evolve an emergent solution to complex problems. Yet this is usually glossed over when showing Test Driven Development.

But not in this session. Here we are going to focus completely on Fake it till you make it. Taking complex katas and reducing them to

1 Red - 1 Green - 40 Refactors.

In this session, we are going to look at 3 different techniques that are remarkably powerful in combination to cut through legacy code without having to go through the bother of reading or understanding it.

The techniques are: Combination Testing: to get 100% test coverage quickly Code Coverage as guidance: to help us make decisions about inputs and deletion Provable Refactorings: to help us change code without having to worry about it. In combination, these 3 techniques can quickly make impossible tasks trivial.

We will be doing this on the Gilded Rose Kata (https://github.com/emilybache/GildedR…. It is extra beneficial if you try it out yourself first so you can see how your implementation would differ but this is not required.

Like everyone else, you have a large product that is hard to work with. We're going to change that in 75 minutes. Together we will save some gnarly legacy code (one thousand-line function). We will start with something hard to read, untested, and possibly buggy. We will finish with code that is stupidly easy to modify. You'll learn 6 trivial techniques that you can apply over and over to fix 95% of the messiest code you have. You can take home this exercise to help the rest of your team learn these techniques. You'll also learn how your team can teach itself a bunch more techniques to handle the other 5%.

We are going to save some legacy code. In 90 minutes. While adding features. We will mob program; you will save this legacy code. We won't introduce any bugs along the way. We will spend the time that you would normally use reading code to instead make it readable. You can apply these techniques and reduce the cost of coding within 48 hours of getting home.
We have done this exercise with dozens of teams. They code differently now. Changing existing code is actually safer and cheaper than writing new code. Their designs get a little better each day. This session will improve your code and show you what skills to learn to gain further improvements.

Learning Outcomes:
Know the 6 refactorings required for reading code by refactoring it.
Differentiate between refactoring and micro-rewrites (code editing), and choose each where appropriate.
Have fluency in the key refactorings with one tool set and know how to spread that fluency to other tools and to broaden the skills within that tool set.
Able to start successfully saving legacy code without making major investments, even with no tests.
See an obvious path for continuing to learn design and refactoring skills - know where and how to get feedback and can create own curriculum for next 1.5-3 years of improvements.

Over the course of my life I have amassed a great quantity of 1-3 minute talks. Tonight we are going to Randomly pick from that list and see where the adventure takes us!

Talks:
Test Driven Math
10 X
A swimming pool isn’t just a bigger bathtub
Bdd vs TDD
Arlo’s Git Notation
The Curse of knowledge
Do NOT use the greater than sign in programming
DocDoD
Sparrows
Leveling up
On being the best
Quantum Computing
Theory Based thread testing
Better Lunches
Decision trees
Sustainable Pace
Standing alone
Better Interviews
Duplication and Cohesion
Generic Type Information at Runtime in Java
Make the easy change

“All the brilliant people, working on the same thing, at the same time, in the same space, and at the same computer.“ - that is Mob Programming. When the activity we mob on is exploratory testing, or the viewpoint to being a programming mob is that of an exploratory tester, we call it Mob Testing. Mob testing - a group testing activity utilizing one computer - voices out the tacit knowledge in the group of individuals on shared tasks. Facilitated by an expert, it makes a great mechanism for building habits and transferring skills over passing knowledge.

In this workshop, we amp up our testing skills by learning from one another, and learn in a mob, getting the best knowledge out of the team into the task at hand. With mob testing, we get a glimpse into the head of the testers while they test because “for an idea to go from your head to the computer, it must go through someone else’s hands”. This is a specific communication style called Strong-style pairing, and it connects the group of brilliant minds in the mob in a shared experience.

The workshop gives you ideas on:
How mobbing gets the tacit knowledge out in a team in an actionable format
How to introduce learning in mobbing format at your place of work
What would it look like to think like an exploratory tester, with intent of understanding coverage while uncovering useful information
What would it look like to apply testing skills while joining a group programming activity
How you can improve your collaboration skills in hands-on work

We will set the room up to two main roles: the mob and the observers in the fashion shown in the picture below. Observers can rotate into the mob and throughout the session play a significant role in regular retrospectives distilling learnings. Don't be afraid, you will not need technical skills to join the mob.

If you think pairing programming ( 2 people on 1 computer ) is crazy, hold onto your hats; it’s time for Mob Programming.

Mob Programming: All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer.

We are going to take a look at a new way of working, what it looks like, and why it can work. More importantly, we’ll have a (very) short session of actual mobbing, so you can see for yourself and come to your own conclusions.

If you think pairing programming ( 2 people on 1 computer ) is crazy, hold onto your hats; it’s time for Mob Programming.

Mob Programming: All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer.

We are going to take a look at a new way of working, what it looks like, and why it can work. More importantly, we’ll have a (very) short session of actual mobbing, so you can see for yourself and come to your own conclusions.

The goal: Clean Code That Works, and getting there is half the fun. Working with a legacy mess can be frustrating, boring, dangerous, and time-consuming. When FIBS occur (FIBs = Fixes that Introduce Bugs) you often enter an endless Test and Fix cycle that can quickly escalate into a nightmare. I've been there, you've been there. How do we return to pleasant dreams?

In this code-centric workshop we'll look at ways to introduce sanity and calmness into the process of maintaining and improving buggy, poorly written, poorly designed code. Few slides, mostly code. Learn how to turn any project around and have fun doing it.

This is a high level talk about many of the misconceptions surrounding refactoring, including
What refactoring looks like
Why refactoring is often neglected
The pace of change
Making better choices
The ROI on improvements

This talk is broken in 5 sections:

Evolutionary design
The most common misconception is that refactoring is a mini-rewrite of a section of code. Instead we are going to look into what microevolution looks and feels like. As well and the double edged sword as to why it is both extremely successful yet often unappreciated.

Code Smells
Using cutting edge pattern recognizing training we will show managers and programmers alike how to spot bad code at a glance

Naming

Explore Arlo Belshee 7 steps of improving the naming of your code.

10 X
The ROI (return on investment) is one of the most misunderstood part, because the math is very non-intuitive. Here we will explore why 8,402 is 10 times better than 8,333 ?!?

'Times they are a changing'

The programmers of 2024/2025 will look nothing like the programmers of the past. As this transition is in progress I have been actively working to understand what the new world will look like. We're not just coding; we're revolutionizing how we code with AI. Imagine a world where Test-Driven Development (TDD) meets the incredible power of AI tools like ChatGPT and Copilot. That's what we're exploring together!

What's Cooking?
In this session, we'll dive deep into how TDD is not just surviving but thriving with the AI evolution. It's not about the code we write; it's about how we write it, test it, and evolve it with AI's help. I'll share my experiences, the cool tricks I've learned, and how our coding skills transform when AI joins the party

Live Coding Adventure:
“Get ready for an action-packed live coding experience! We'll kick off projects, refactor existing ones, and, most importantly, have fun while learning. I’ll take you through the art of prompt engineering for refactoring and how to structure tests (and comments) to support the best generation of code.

Flexibility and Relevance:
“The tech world moves fast, and so do we. The content of this session is as dynamic as the field of AI itself. So it might be different come July. I'll stay on top of the latest trends and tools, so what you get is fresh, relevant, and ready to apply.”

Learning Outcomes
New Code
Using AI + Tests to generate code
Using AI to generate useful examples
Using AI to understand existing code
Refactoring
Creating full test coverage
Renaming variables and methods
Splitting long methods

The system crashes in a portion of the codebase you have never seen. It is Friday night, 4 o'clock pm, and you have to fix it before you can go home. How can you accelerate your understanding of the bug and still get out of the office before 5?

Learn to use two simple techniques to isolate the problem by dividing and conquering code without necessarily understanding it. Once the problem has been isolated you will have a suite of tests that replicate the error, and allows you to simply debug to find the problem. After the problem is found, and you have tests replicating the error, you will have everything you need to fix it.

When open-source projects don’t have good documentation, most people don’t use them but this is not an option when you have to use the code developed with other teams within your own company. Then, you have to use it and the lack of documentation can lead to frustration and even desperation. Why doesn’t good internal documentation exist? The problem is threefold:

If you understand everything it is hard to know what is confusing to others

If you don’t know things, you know what you wish existed but you can’t write it yourself

Even if you have both people present, it is still hard to write good documentation

In this session, I will show you how to solve all three problems.