Some years back I realized my most beloved parts of our software movement could be characterized as re-balancing our approach towards the triad of Made, Makers, and Making, and away from a prior focus only on the Made. Let’s schmooze about this.
I once again point out: geekery isn’t terribly important right now to me. What’s important is my friends and family out there working on the crisis.
Stay safe, stay strong, stay kind, stay angry. Black lives matter. I am so proud of you: Keep pushing for change.
First of all, what do I even mean, about this adjustment of focus? For easy writing and reading, I’ll treat this as a Before & After thing, even tho I know full well that’s a fiction, for two reasons.
First, although "Agile" is the buzzword of the decade, it’s still not a majority or even plurality in market share. That is, a great many orgs haven’t even tried to step into this After.
Second, because "Agile" is the buzzword of the decade, a great many orgs claim "Agile" with very little of actual agility in their world. "Agile" has succeeded modestly by becoming, in many cases, a silly re-naming effort rather than an actual embrace of change.
But I’m sticking with Before/After, tho it’s fictional, just to try to lay out what I’m talking about at all.
The software trade is about creating artifacts, "programs". These artifacts are what I call The Made. They include every aspect of the artifact that is visible to a user of it.
Of course, these artifacts don’t spring Athena-like from the head of a god. No, these Mades are created over time. Those acts of creation represent what I call The Making. The Making is all about the path from no-Made to Made, the route we take during that non-zero time.
And when we have acts, you might suppose, you also have actors performing those acts, and these are the Makers, the actual humans who are Making the Made.
(Careful: the Makers is not a group limited to people who type code: lots of people who are not programmers are Makers.)
So we have Makers, Making, and Made. The case I’ll make is that the agility movement can be described as starting from a Before in which the Made was the center of all theory, towards an After in which the center is an equal balance of all three concerns.
Oh, one other important aspect: Don’t look for crisp black lines demarcating all this. In 1968, Dijkstra’s famous "Goto Considered Harmful" letter was clearly already concerned with the Making and the Makers. I’m talking about trends and motion here, not geometry.
Let’s take a simple case to illustrate some of this abstraction. Test-Driven Development, or TDD, is clearly one of the centerpieces of the agility movement. Tho not as widely practiced as it could be, from a perspective of pure "technique", it’s an impressive win.
TDD has three features that don’t really exist in well-known forms before its creation: It is iterative, developer-centric, and precedes QA. Tho some folks did something like it during the Before time, it was never publicized, formalized, or widely promulgated as technique.
Iterative means that TDD is a process of stepwise enhancement. Think of the way images form on a slow internet connection, or the way professional artists actually draw, by a process of gradual refinement and elaboration. There is nearly zero discussion of this idea before 1990.
Developer-centric means simply that the people who apply the technique of TDD are the actual programmers, the exact same people who write the code write the TDD tests. Again, there were spotty instances of this during Before, but nothing like the spread of it today.
And pre-QA means that TDD is done much earlier in the process of creation than it had ever been done before. TDD tests are written immediately before the code that is meant to pass them. Again, you can spend all day prowling classic sources and find no inkling of this notion.
These features of TDD are actually pretty revolutionary, which accounts in part for its still relatively slow spread.
(I regard the periodic counter-TDD surges to have less to do with revolution and more to do with lousy pedagogy, a topic for another day.)
The crux of the case: The After — TDD — has much more to do with the Making and the Makers than any established software development technique from the Before.
How does being iterative, developer-centric, and pre-QA, concern itself with the Making and the Makers?
Oh I’m so glad you asked. 🙂
The iterative stepwise evolution from TDD is in stark contrast to the "finality" of the Made. A TDD test is just a step. We write them not because they’re part of the Made, but because they help us optimize our Making, step by step.
TDD’s benefit is largely operational, a topic I’ve waxed wordily on several times in the past. And who takes that operational benefit? Oh yes. The Makers do.
TDD Pro-Tip: Test-Before Is Operationally Different | GeePawHill.org
Because the power of TDD is operational rather than artifactual, test-before provides several benefits over test-after.
TDD leans into the humanness of the Makers in several ways, but two key ones: 1) it respects the strict limit humans have on their mental bandwidth. And 2) it rhythmically distributes reward to its human practitioners.
(We don’t make nearly a big enough deal out of the human-leaning aspect of TDD, a source of high dudgeon for me. The way TDD affects humans operationally is a very significant factor in why it works so well.)
Finally, the pre-QA aspect is a big signifier. The standard shape of the trade from the ’90s on is that a group of people, called QA, serve as a gateway to release. In other words, they’re the last check before a thing Makers are Making becomes the Made.
But TDD occurs far earlier in the making process. Far from being the last step to shipping the Made, at it’s best it’s the first step of the Making.
So, obviously, I’m asking here for a friendly ear: this is all fuzzy and attitudinal. But I think if you puzzle on this, especially if you’ve really done work in Before environments and After environments, you’ll be able to hear it, too.
Before I wrap up, let me toss out some other examples of this. For these, I won’t offer any detail, today, just give you a quick napkin-sketch/head-nod for each.
Refactoring is literally changing the design of the Made without changing its function. In a Made-centric world, it makes no sense. And I remind folks, the computer doesn’t care about the design of the code. Only the human Makers do. And they do, because it improves their Making.
Working-by-story isn’t inherently iterative, but having noticed the enormous benefit in plan-value that comes from smaller stories, we reach a natural balance of incremental & iterative. Tho the imagined Made is the target of the stories, they greatly impact the Making & Makers.
Pairing and mobbing are even more operationally beneficial than TDD. As such, they short the focus on Made, evenly splitting their influence on Making and Makers. Groups drive energy & insight & learning far more than any Before practice does.
One odd way to reassure yourself that these practices of agility change the balance? If you’re adopting them now, or you’ve already done so, notice the shape of the arguments against. Notice how often they ignore the Making and the Makers in their reasoning.
There’s more, lots more, but I got me a retro to attend in a few minutes, so let’s wrap this bad boy up.
When I think about what my agility truly is, what I think about is the breadth of focus: our movement is, in many ways, a movement about refocusing our methods, to incorporate not merely the Made, but also the Making itself, and the Makers who do it.
This week, whatever practices you have in place at your shop, ask yourself, do they care about the Making and the Makers, or do they only attend to the Made?
And get back to me. 🙂
Supporting The PawCast
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. Support GeePaw Here.
This is great perspective on how to think about the impact, benefits and beneficiaries of TDD and Pair/Mob. Thanks!