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”
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”
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?”
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”
I see pairing as similar to a language. So I figured I’d put together a phrasebook for those who are just learning to pair. You might find these useful as you are trying to locate the bathroom, train station, and restaraunt in PairingLand. Continue reading “A Pairing Phrasebook”
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”
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”
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?”
An overheard conversation at work got me thinking while I was headed home. I’ve now got to send some of those thoughts your way.
The one guy was arguing against agile on the basis that it “throws the baby out with the bathwater” with respect to design. Me made several statements. Some are true, some are partially true, and some are flat false. These statements are:
- There is still a role for design when trying to release quickly (true).
- Agile throws design out the window (mostly false).
- Agile only works with 5 people, in one room (false).
- Agile ships prototypes, not real code (false, but an easy misinterpretation from a true statement: agile teams always ship the simplest thing that could possibly give them the feedback they need).
Assuming the above represents his position, I would respond as follows. Continue reading “Agile vs Design”