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 [...]
Archive for the ‘post’ Category
Spinning up a new team
Posted in post, tagged coach, experience report, story, transition on April 10, 2013 | Leave a Comment »
The No Mocks Book
Posted in post, tagged design, no mocks, tdd on December 18, 2012 | 18 Comments »
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 [...]
Fixing Legacy: What Should I Blow Up First?
Posted in post, tagged legacy code, refactoring, technical debt on October 16, 2012 | 2 Comments »
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 [...]
Paying Down Code Debt
Posted in post, tagged code debt, legacy code on September 18, 2012 | 8 Comments »
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 [...]
A Pairing Phrasebook
Posted in post, tagged Agile, fluency, pair programming, proficiency on July 24, 2012 | 3 Comments »
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.
Mock Free Example 4: Everything’s Better with Async
Posted in post, tagged design, example, no mocks on July 17, 2012 | 2 Comments »
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 [...]
Easily Eliminate Most Mocks
Posted in post, tagged design, example, no mocks, tdd on July 15, 2012 | 9 Comments »
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. [...]
Hamlet On Branching
Posted in post, tagged Agile, branching on May 21, 2012 | 3 Comments »
To branch, and when to branch: that is the question: Whether ’tis nobler in the mind to suffer The slings and arrows of poor integration, Or to take arms against a sea of features, And by swarming end them? To end: to ship;
Is Pair Programming for Me?
Posted in post, tagged Agile, learning, pair programming, pairing on May 15, 2012 | 20 Comments »
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 [...]
Agile vs Design
Posted in post, tagged Agile, design, feedback on May 10, 2012 | 2 Comments »
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 [...]
