Muses

TDD Pro-Tip: Against Automated Macrotests

TDD, Programming, How I Work, Coding / / 9 minutes of reading

TDD Pro-Tip: I advocate against automated macro-tests — those whose base is entire running programs –, as their cost is high and their benefit is doubtful. I very rarely write them. There is a bewildering variety of terminology out there around what I’m calling macro-tests, so let’s poke around a little. The central idea of "macro-test" is that we write code that launches an entire subject program and probes its behavior "from the outside". There are often multiple programs in […]

TDD Pro-Tip: Against Automated Macrotests See Full Post

Some TDD History

TDD / / 7 minutes of reading

I spoze the historic and ongoing inability/unwillingness of the software trade to grasp and adopt test-driven development (TDD) is one of the most frustrating & demoralizing events of my forty-two years as a professional geek. I believe there are several related factors in play, ranging in abstraction level from pressures of global ieconmics to mistakes in local human interaction. Studying this large-scale failure, even while having some small-scale successes, underlies much of my work on change. Because, while the overall

Some TDD History See Full Post

On Over-Coding

How I Work, TDD, Programming, Coding / / 4 minutes of reading

Let’s talk for a minute about "over-coding". Over-coding, when you’re a TDD’ist, is writing more code than you (intended to) have test to cover. But I will offer a few thoughts on this to non TDD’ers and TDD’ers alike. Many people, pro-TDD and con- both, seem to think of TDD as the name for a collection or rigorous mechanical rules. TDD is a kind of jack-in-the-box, where you sit there and turn the handle, circle circle circle, and out pops

On Over-Coding See Full Post

Ten I-Statements About Change

Coaching, Change Harvesting / / 6 minutes of reading
This entry is part 1 of 5 in the series Leading Technical Change

Here’s ten I-Statements about change, in the geek trades, and beyond. My hope is that it will give you a richer sense of where I’m coming from in my blogs, talks, videos, and courses. Before we begin, though these statements are about the geek trades, I am actually far more concerned with change in the world. We can change this. We’re the only thing that possibly can. Stay safe, stay strong, stay angry, stay kind. Black Lives Matter. A little

Ten I-Statements About Change See Full Post

Trade Collapse Begins?

Change Harvesting / / 3 minutes of reading

I’ve oft mentioned how the twin cost-revolutions in geekery warped & nearly destroyed our trade. Then wondered if we’ll get to a place where it’s no longer profitable for most companies to write bad software poorly. This morning I wonder if I’m seeing the beginning of it. I don’t have any facts & figures for you. But it feels like I’m seeing more and more companies wonder if the gravy train’s caboose will soon pass the station. It won’t happen

Trade Collapse Begins? See Full Post

On Not Knowing

Programming / / 4 minutes of reading

When I was a wee lad, 28, 29, 30, I knew the C Windows API by heart. I had, in my bathroom, both the technical docs and a copy of Petzold, and I knew it cold, stone cold. Every one of the ~500 calls, all of the arguments, and for most of them, the order of the arguments. I was a good programmer because I was a terrific memorist: I could learn things by heart, and I could organize them

On Not Knowing See Full Post

The Shadows of Software Design

Programming, Modern-Synthesis, How I Work / / 7 minutes of reading

On the cover of Hofstadter’s famous Godel, Escher, and Bach, there’s a photo of an artifact he made, called a "trip-let". The trip-let, when lit from three different angles, produces shadows that spell out "G", "E", and "B". Let’s talk about software design. Before we dig in: I love to think & talk about geekery, but it’s comfort food, not my most important story. Take a break, enjoy this thread, but please stay in the larger game with me, which

The Shadows of Software Design See Full Post

Me, Gary, and TDD

TDD, Programming / / 4 minutes of reading

True story: Eighteen or so years ago, I had a gig rolling code at an engineering company. We were writing a windows app using Microsoft Foundation Classes to drive a TTY interface to a box of various radio hardware junk. I was gigged in by a guy I’d taught a c;ass (in MFC) to, because he liked that I knew my shit, and he loved that I spoke openly about joy, right in the classroom. right in front of God

Me, Gary, and TDD See Full Post

MMMSS – The Pin-Making Floptimization

Change Harvesting / / 10 minutes of reading
This entry is part 5 of 5 in the series Many More Much Smaller Steps

In our efforts to optimize the Many More Much Smaller Steps (MMMSS) path, we’ve tried and rejected the "shortest-distance" floptimization. Today, let’s take up the "pin-making" floptimization, in which we create specialists, stations, and hand-offs. Many More Much Smaller Steps – First Sketch | GeePawHill.org The first plank of my take on fixing the trade is MMMSS: If you want more value faster, take Many More Much Smaller Steps. Today I want to start laying this out for folks. This

MMMSS – The Pin-Making Floptimization See Full Post

MMMSS – The Shortest-Distance Floptimization

Change Harvesting / / 10 minutes of reading
This entry is part 4 of 5 in the series Many More Much Smaller Steps

We’ve built ourselves a positive case for "Many More Much Smaller Steps" (MMMSS). There’s a counter-case, tho, based in a trio of proposed optimizations. Sadly, those optimizations usually flop. Today, let’s take up the "Shortest Distance" floptimization. Many More Much Smaller Steps – First Sketch | GeePawHill.org The first plank of my take on fixing the trade is MMMSS: If you want more value faster, take Many More Much Smaller Steps. Today I want to start laying this out for

MMMSS – The Shortest-Distance Floptimization See Full Post

Scroll to Top