Pro-Tip

TDD Pro-Tip: Suspect Sentinel Returns

TDD Pro-Tip: I suspect sentinel returns, and though I still use them, it’s generally because I haven’t found the right formulation yet. I’m working on the TSD project today, and I’ve got a nasty little chunk of code I wish weren’t nasty. (It’s in this file, and of course, you’re welcome to grab the whole repo, which will enable you to really make fun of me.) You don’t have to look at the code, I’m not going into it, but […]

TDD Pro-Tip: Suspect Sentinel Returns See Full Post

Change Pro-Tip: Reset

Change Pro-Tip: I sometimes will take an individual or group relationship of mine and ask for an explicit "reset". It’s not a frequent solution, but when the circumstances are right, the rewards for doing it can be huge. Early last year, I was in a wrangle with a person I’ve known for a few years. It wasn’t a crisis, exactly, but it wasn’t a happy or even neutral relationship. He called me, and as we spoke it became ever more

Change Pro-Tip: Reset See Full Post

TDD Pro-Tip: Make The Tacit Explicit

Refactoring Pro-Tip: When I make tacit relationships explicit I nearly always improve my code. Once I move past syntactical refactorings into semantics, this is often my first set of moves. So what does this mean, "tacit" vs "explicit", in code? Maybe the easiest way to come at it is with a very dumb example. The simplest tacit relationship I can think of is modeling a one-to-one relationship using two lists. The first list is composed of tokens. The second list

TDD Pro-Tip: Make The Tacit Explicit See Full Post

When To Start Doing TDD

TDD Pro-Tip: TDD-blockers are everywhere for me, even now, after twenty years of practicing it, so I still try new ways to work around them, and I don’t always find them, and I wait for next time. A respondent had a great question, and this is a kind of "sideways" answer. The question: Given that we’re halfway through an app w/o an architecture that TDD’s well, should we start TDD now or wait for the next greenfield chance to do

When To Start Doing TDD See Full Post

Coaching Pro-Tip: Read More Narratives

A new coach in the VBCA[*] world asked me what she should be studying. What, she asked, should she be reading, to get good at promulgating change in her large org? [*] – Very Big Corporation of America, see Monty Python. She proposed a bunch of topics, including management, psychology, sociology, a variety of geekery sub-topics. My answer: anything narrative, especially great novels and great history. She, as you might expect, splutter-laughed. I have read any number of works in

Coaching Pro-Tip: Read More Narratives See Full Post

Large Stories Mean Side-By-Side Technique

When I have to have WIP that’s live in production, I pretty much have to use all the approaches for side-by-side development. In some recent muses, we’ve talked about "in situ" vs "side-by-side" approaches to changing code. First, let’s refresh our concepts for these two phrases. In both cases, we have a bunch of code A, and we wish we had a bunch of code B. B might incorporate all of A, or it might be more like A’, or

Large Stories Mean Side-By-Side Technique See Full Post

Run Once, Run Away (RORA) Even Bites Pros

TDD Pro-Tip: RORA (Run Once, Run Away) is insidious, and although I am an old-guard agilist, I still have to actively resist its charms every day. Alright, well, look, I figured out after some helpful application of 2×4’s to the head, that I needed to phrase these pro-tips as advice to me, even when, as occasionally, in my heart of hearts, I thought of it as advice for you. This is not one of those cases. I’ve been working on

Run Once, Run Away (RORA) Even Bites Pros See Full Post

Steering Around The Pyramid Problem

TDD Pro-Tip: An important steerability force for me is in my strategies for sidestepping the pyramid problem. There are a lot of ways we could describe this "pyramid problem". Perhaps the most straightforward way is to ask how much code is "in play" during a test. At some point, and it varies by codebase, the answer becomes "a lot". When it does, you’re encountering the pyramid problem. I call it the pyramid problem because I see code as great big

Steering Around The Pyramid Problem See Full Post

TDD Pro-Tip: Make Hard Problems Collections Of Toy Problems

Because TDD’ing little toy problems is so easy, I try to turn my big real-world problems into collections of them. Yeah, it’s the steering premise rearing it’s ugly head again, though maybe from a different angle than we’ve undertaken before. (The short premises video is here) A lot of folks claim that TDD is just fine as long as you don’t work on their kind of problem. They mean that their daily bread is made from problems that are VERY

TDD Pro-Tip: Make Hard Problems Collections Of Toy Problems See Full Post

Change Pro-Tip: Experiments, Cheating, and Responsibility

If your change works, and if it’s small enough to take at one gulp, Then you might consider de-emphasizing the argument for adoption, and focusing your powers on gaining an experiment. (If you change doesn’t work, or it’s too big to take at one gulp, then you might want to go back to the drawing board.) Experiments are significantly easier to get than pre-argued pre-justified pre-determined change. Even very conservative teams can be convinced to try a small thing in

Change Pro-Tip: Experiments, Cheating, and Responsibility See Full Post

Scroll to Top