July 2019

Run Once, Run Away (RORA) Even Bites Pros

Coaching, Pro-Tip, TDD, Change / / 5 minutes of reading

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

Change, Coaching, Pro-Tip, TDD / / 4 minutes of reading

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

Change, Coaching, Pro-Tip, TDD / / 5 minutes of reading

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

Coaching, Pro-Tip, Change / / 4 minutes of reading

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

Using Kotlin for Data Builders

Change, Coaching, Kotlin / / 4 minutes of reading

In Kotlin, functions whose last argument is a lambda, i call them end-lambda’s, make natural expressions of tree-shaped data builders. Say you’re building Performances, where a Performance includes (possibly) the list of songs being performed. making shit up here, it might look like: performance { song { } song { } } First thing you notice: this thing is building some tree-shaped data, and it’s tree-shaped. None of this "song1= … song2= … performance = Performance(song1, song2) shit. If you’re

Using Kotlin for Data Builders See Full Post

Great Geeks Are Great Humans

Change, Coaching / / 1 minute of reading

You can’t be a great geek w/o being a great human. I get how the tradition says you can. I get how much you wish it were so. You can’t be a great geek w/o being a great human. Being a great human is fabulously hard. It’s the hardest thing humans have ever conceived of. So, raise your game. I need to raise my game. We need to raise our game. You beat the first boss handily. You found the

Great Geeks Are Great Humans See Full Post

Refactor Your Tests

Change, Pro-Tip, TDD / / 4 minutes of reading

TDD Pro-Tip: I spend considerable effort making it possible not only to implement a test I want, but to make that test easy to read, to write, to run, and to debug. I’ve talked a lot about five premises of TDD. The money premise, the steering premise, and the chaining premise all get involved when we come to the coding of the tests. We do TDD to ship more value faster, the money premise. What makes it able to do

Refactor Your Tests See Full Post

Try Different, Not Harder

Coaching, Change / / 5 minutes of reading

Change Pro-Tip: I give the same advice to myself as a coach that I do to my teams: "Try Different, Not Harder". A while back we covered Alice’s vision of how to change things. In countering it, I offered the adjustment "from final to iterative". The idea of iterative change is straightforward: It means that we change a thing, and then later we change it again, and still later we may change it again. I want to be sure we

Try Different, Not Harder See Full Post

A Question Of Humbling Proportion

Coaching, Geekery, Modern-Synthesis / / 2 minutes of reading

The road to hell is lined with convenient parking spaces. I said recently that we need fewer addresses and more routes. These slugs are attempts to get at what I think keeps going wrong for us — in the trade, possibly in entire culture. There are numerous systems for software development out there competing in mindspace. (Stock word for these is "methodology," but I resist. I’ll call them "methods", as to my reading, methodology is the study of methods.) Every

A Question Of Humbling Proportion See Full Post

Create Experiences Not Arguments

Change, Coaching, Pro-Tip / / 4 minutes of reading

Change Pro-Tip: When I can give people an experience, I get dramatically better results than when I give them reasoning. I’mo tell you one of my stories. Twenty years ago, with a considerable amount of "Shut up, I’m the pro from Dover", I got permission to do TDD in a corner of the app I was working on, an app that walked remote groundstations through reconfiguration using a "console". My buddy and boss Gary was unimpressed, but I had permission,

Create Experiences Not Arguments See Full Post

Scroll to Top