Coaching Day 1: Getting a clean liftoff

The Scheme

I want to get the team off to a good, clean start.

My challenge is that we are not used to working collaboratively in this group / company. The point of this experiment is to work collaboratively and to see how that impacts productivity and flexibility. For example, what does the ramp-up cost look like to work in an area where only one person is a SME?

Therefore, everything I do today is focused on ensuring a collaborative team. Continue reading “Coaching Day 1: Getting a clean liftoff”

Spinning up a new team

I am forming a new team. We are doing this as an experiment, so we are documenting the heck out of it. As part of this effort, I am publishing “Coach Arlo’s Secret Agenda”—a daily journal of what I intend to teach each day and what the results were. This is/will be a name-scrubbed version of that series.

Welcome inside my mind as I go through each day and detail of spinning up a new team and transitioning it to agile at the same time. Continue reading “Spinning up a new team”

The No Mocks Book

Recently on twitter, Clayton asked for a good book about unit testing without mocks. I don’t believe such a thing can be written, so I’ll try to write it in one blog post. First, here it is in one sentence:

Mocks are a smell. They tell you that your code depends on some semi-related part of the system. Rather than work around the design defect, fix the design.

The trick is figuring out what smell you are observing and how to “fix” it. Basically, what alternatives exist. Down the rabbit hole we go. Continue reading “The No Mocks Book”

Fixing Legacy: What Should I Blow Up First?

Another good question came over the wires at work. My reply grew too long and I figured more people would want to see it. Besides, this way I can blog and call it a legitimate business activity.

Problem statement: what patterns and strategies work for choosing when and what to refactor? Does this change at scale? Continue reading “Fixing Legacy: What Should I Blow Up First?”

Paying Down Code Debt

We have huge code debt. We want to pay it down. But we just can’t afford to this week (or last, or the one before that). How can we afford to pay down our debt?

OK, it’s not a direct quote. But I’ve heard something close to that often enough that random word ordering may have actually created exactly that statement at some point.

Here is a set of techniques that I’ve used in the past to start paying down debt in situations where we were all sure we’d never be able to afford to. Continue reading “Paying Down Code Debt”

Mock Free Example 4: Everything’s Better with Async

In the previous post in this series (“last week” to those who didn’t read it over a year ago), I made simple code complicated in the effort to make it unit testable. It was all going along fine, until I started bringing functional programming into the mix.

Since that worked so well, I’m going to demonstrate how I really wrote the code, which brings in functional programming, laziness, and asynchronous programming.

Continue reading “Mock Free Example 4: Everything’s Better with Async”

Easily Eliminate Most Mocks

In previous discussions about mock-free unit testing, I’ve shown techniques that I use to eliminate the hard-to-eliminate test doubles. I’ve skipped the simple techniques that I apply all the time. Time to fix that.

One technique eliminated about 90% of the test doubles in my code. It’s simple. It’s been around for a long time. Odds are you already do it but not frequently enough. It even has a name:

Extract Method. Continue reading “Easily Eliminate Most Mocks”

Is Pair Programming for Me?

I have noticed a significant difference in the results achieved by teams with pairing depending on how they approach learning to pair.

In particular, many people don’t expect pairing, itself, to be a skill. They don’t realize that they’re going to have to learn new ways to think, to problem solve, to be creative, to filter their perceptions, and even to converse. Since they don’t realize this, they get surprised. And then they set themselves up to make that learning hard, and quit when they get poor results and find pairing to be hard while learning. Continue reading “Is Pair Programming for Me?”