TDD journeyfolk, let me rattle your cage a little this fine afternoon. Lemme sketch a common situation for me. I have a problem, not a small one, to be solved in a tech stack I’m not intimately familiar with. Further, some aspects of the problem are things no one on stack overflow has ever done […]
Crabby Note To TDD Journeyfolk Read More »
Yesterday, I started my explanation about not using automockers. But that muse is about just one aspect of the automocking world: interaction tests. And automockers can do a lot more than that. We could use an automocker for years without ever writing an interaction test. So, then, again, why don’t I? I’m an old fart,
Automocking: Don’t Take Hard Shots Read More »
So, with the intent firmly in our minds, from yesterday, I feel closer to explaining my automock resistance. There is still some teasing apart to do. Automocking tools bring several possible aspects to the floor. The first of these is by no means required by automockers, but is commonplace. And that is behavior-based testing. Behavior-based
Automocking: Behavior Tests Are Not Quite Read More »
(When I’m teaching and coaching, I have a number of premises that I discuss and that will show up somewhere in everything I do. Here’s the money premise, which I usually bring up at the earliest opportunity.) Look, kids, we’re in this for the money. Somehow you got the idea that TDD, pairing, micro-stepping, and
We’re In This For The Money Read More »
I don’t "believe" in logs, generally. What I mean is, for developers, logs should be seen strictly as a story for ops, not a development tool. I understand why ops needs to see logs. Ops is a customer just like any other, and what they need, we can supply. But I see far too many
Stop Using Logs Everyday Read More »
Defining Agile Sooooo, I saw a couple folks arguing earlier about what is or isn’t Agile. That’s okay. People do that. Analytical people thrive on doing that. Anyone who’s gotten to the level of journeyfolk in any arena will seek to define that arena. All very healthy stuff. Nowadays I tend to avoid these arguments.
Defining Agile: A Musing Read More »
User Stories If you are concerned about how you write a user story, you have missed the entire point. A user story is a little card that reminds us of all the actual conversations we’re currently actually having. If the words "bathtub farting" are enough for the team to actually converse about what they signify,
User Stories Are Playing Pieces: The “Right Writing” Is Wrong Read More »
I’ve been having a lot of trouble getting to sleep lately. I go to bed cuz it feels like it’s time. Sometimes my body won’t settle, itching and twitching and such like. Sometimes my mind won’t. Usually it’s a mixture of both. So I get back up. But then I’m tired as hell, and it
Me & Molly & Marvelling Read More »
EDIT: This premise has been renamed the "Steering Premise", you can see the full video breakdown here. The Driven Premise Here’s an illustration of the most basic principle of TDD, what I call the "Driven Premise": there once was a queen who had a thousand consorts, each more brave and handsome than the next. But
The Driven Premise Read More »
Assumption-Boxing I’m thinking of maybe a new geepaw coinage: something like "assumption-boxing". This is when we frame a problem with an assumption that narrowly limits (boxes) the range of solutions. A real-world example we’re all familiar with: "Optimize meeting structure to exchange status reports on individual’s sub-projects". Do you see that "meeting structure" is a
Assumption-Boxing is Harmful Read More »
