Modern-Synthesis

The Baseless Critique Of Living Branchlessly

This branching thing. The idea behind branching is that it provides advantages in situations where a code change is large. The idea behind non-branching is not to enter those situations. These two views seem very difficult to reconcile. I am a non-brancher. I push to head, I pull from head, I test on head, I ship from head. Let’s take a second to consider the arguments against living like this. First, a whole team that lives like this is constantly […]

The Baseless Critique Of Living Branchlessly See Full Post

Endpointing vs. Next-Stepping

I mentioned endpointing yesterday. I’m always using geepaw-isms & expecting people to know what I mean. Endpointing is over-focus on eventual destination. In s/w, it’s seeing development as a long trip to a known destination on a known map. John Winthrop, a few centuries back, used "the city on the hill" to describe an endpoint, in his case for the puritan colony. The metaphor, of a trip to a place, is as natural as any human expression. But it contains

Endpointing vs. Next-Stepping See Full Post

“Avoid Changing Code” Should Be Avoided

Of all the bad advice the geek trades inherit from over-simplified manufacturing & engineering, perhaps the worst: "avoid changing code". Take a minute, and think of all the things the trade does to avoid changing code. Virtually every element of "big design up front" policy is based in this view. Long stretches for analysis, longer ones for design. Planning cycles that extend years into the future. Years. I am not exaggerating for effect. Years. Contract-like specifications, database designs that start

“Avoid Changing Code” Should Be Avoided See Full Post

Using Strategy & Function-Specific To Attack Large Classes

In IT work — "it puts the database on its browser skin" — we often face sooner or later the problem of the gigantic object. Some systems, especially "global monolith reboots", just start there. Others just grow and grow and insensibly slide into it over time. The problem is that there are one or a few objects that are just plain central to the domain. To forestall ron and his marick quote, I’ll use the classic ‘order’ as my example

Using Strategy & Function-Specific To Attack Large Classes See Full Post

When I Need to Not Pair

So, a friend asked me to say more about "not pairing". As so often, it triggered me to muse. Sometimes I need to not pair. Now, don’t get me wrong, I love pairing. I love it for three reasons. It makes me a better geek. That is, I learn from pairing. Pairing makes two geeks more productive than if they solo’d. That is a pair writes mo’ better code than two solos. PAIRING IS AWESOMELY MORE FUN. But there are

When I Need to Not Pair See Full Post

Reversible Raincoat Tests

Let’s review "reversible raincoat tests." Sometimes, we build systems in which a downstream collaborator must interface with an upstream one. The two apps are by separate teams, on separate servers, developed at separate times, and still both in development. A reversible raincoat test is a script with two sides. Think in terms of a literal script, like in a play. "Mike: hi mom. Mom: hi son. Mike: is today tuesday? Mom: no, doofus, it’s thursday. Mom: gotta go, basement is

Reversible Raincoat Tests See Full Post

On One Ring To Rule Them All?

Yesterday I mused about explanation privileging, where one always reaches for one ring to rule them all in their explanations of behavior. This morning I am thinking about the reasons that happens. Don’t be alarmed, i’m not gonna suggest there’s just one reason for it every time it happens, i’m circular, every argument is circular, true enough, but i’m not that circular. It takes more than one step. 🙂 one reason it happens is biology. There are huge biological reasons

On One Ring To Rule Them All? See Full Post

Why Do We Seek One Ring To Rule Them All?

I’m thinking of this thing called "justifcation privileging," or alternatively "explanation monism". Or even, short hand and jokily, "one ring to rule them all." One constantly sees tweets, blogs, even books, where someone boils down staggeringly complex and ill-understood processes to one factor. Today I saw "people don’t make decisions rationally, they make them emotionally." Now, set aside for the moment that no one even knows what those words mean other than at some vague gut-check level, even then, it’s

Why Do We Seek One Ring To Rule Them All? See Full Post

The First Coaching Days

I can’t over-emphasize for new coaches the importance of rampant opportunism. Until you’ve established your miracle powers in a team, you won’t be able to move big levers, only small ones. Which small levers will bring you the biggest bang of trust & faith the fastest? Some possible openings: we find a bug that’s an exemplar of a family of bugs, and we refactor so it never can occur again. Or we have an untestable, if they’ve started TDD’ing, and

The First Coaching Days See Full Post

Shifting Certainties

Shifting certainties. This is where i’m headed these days. Without belaboring criticism, what i’m seeing is that we have a trade with a whole stack of roles and humans to fill them, and, of necessity, they have assembled a varied, sometimes compatible sometimes not, set of certainties by which they navigate. The trouble is that, even when the certainties align with one another, they, ummm, aren’t. That is, they aren’t certainties at all. Neither our data nor our experience actually

Shifting Certainties See Full Post

Scroll to Top