"Embrace change" is the modern geekery catchphrase for our most basic idea:
We change software, therefore we want everything around us to support that: code, technique, tools, controls, tracking, planning, infrastructure, and above all, culture.
Before we start, remember, geekery’s not the main story right now. The real embrace of change is happening out there on the streets. I fully support my friends & family out there in their quest for equity.
Stay safe, stay strong, stay kind, stay angry. Black lives matter.
The last two decades have added a broad assortment of change-enabling elements to the trade. To get an idea of this breadth, let’s do a little enumeration.
Change, how do we embrace thee? Let me count (some of) the ways…
Three broad features will emerge, so I’m going to call them out now before we get to details. These are a very much heightened focus on collaboration, iteration, and confirmation. They work together and separately to underpin many of the actual techniques & patterns we advocate.
Collaboration: Modern geekery emphasizes direct interactions between individuals in every element of the process. We take much more literally the idea of "working together" than at any point in the trade’s past.
Iteration: nearly all of our praxis concerns itself with identifying, enabling, and executing changes in small steps that continually visit and re-visit our working software. We loop, and each pass through the loop refines & expands what was already there.
Confirmation: the modern style regards validation, at multiple levels and scales, as a central and critical activity. We take great pains to frequently confirm that we know where we are, before we take a step, and where we arrive, after we take one.
As we start the list, hold those themes in mind. You can’t help but notice the extent to which every practice reaches back to one, two, or all three of theme at once.
1. Working by stories.
We make little headlines, on cards, each one describing a change, some small chunk of work to be done, then we use those short notes as tokens in our many conversations. They are not a requirements document, or a contract, but are placeholders for dialogue.
Two features of this approach stand out. First, that stories are changes: they are next-steps for a work in progress, not endpoints in a grand final product. Second, that stories are light and disposable lenses for focusing our collaboration.
2. Continuous integration.
We make our changes directly to "head", the most current version of our codebase, with no branching, batching, syncing, freezing, or staging of changes. Multiple individuals and multiple teams interleave their small changes as each step is finished.
CI, nowadays often called trunk-based development, is based on twin observations about cost. First, that the cost of integration is far lower when you do it more frequently in smaller batches. Second, that the cost of controlling parallel development in other ways is very high.
3. Test-driven development. (TDD)
We make a change by, first, writing a test that runs, and necessarily fails, because the change hasn’t been made. We then do the work needed to have that test pass. We then make the change excellent. Rinse, lather and repeat.
TDD represents some of the most advanced technique in modern geekery. Artifactually, it gives us authority and confidence that our changes are going forward not backward. Much of its value is operational, as it shapes our code, our designs, our worklife, and our thinking.
4. Pairing/Mobbing.
The practice of having multiple individuals actually changing code together, working on the same problem in the same code on the "same" computer. Pairing’s more fluid, mobbing more structured, but the value we gain is similar: many heads make light work.
The key insight this practice brings to the table: reasoning, focusing, engaging, and energizing, these are the hard parts of programming, not typing in syntactically correct code. By multiplying the eyes and minds "in play" on a problem, we get better solutions and productivity.
5. Refactoring.
This is changing the design of our code, its typographical and structural organization, without changing its function. We work, in tiny transformations and large ones, to make the most direct and explicit expression of our intention visible in the code.
If we take the largest three terms in our "daily change productivity function", they are a) the producer’s skill, b) the complexity of the problem, and c) the meaning in code we start with. Of those, by far the easiest and fastest one to improve is the meaning of the code.
6. Retrospectives.
We pause our work at regular intervals, freely and conversationally assessing ourselves, our relationships, our tools, and our method. This is the "meta-" of changing software, it’s changing changing software.
Making software is a creative human act, not a mechanical inorganic one. There are lots of subtle emergent factors that make teams weak or strong. By consciously putting down the tools and looking around at ourselves, we get the opportunity to see those factors, and adjust them.
7. Pull & Swarm.
This is the technique of grabbing a piece of work just-in-time, and surrounding it with as many people as we can to get it done. We eschew look-ahead, and we maximize participation on one story before we pull another for another sub-set of us to swarm.
The idea of P&S, and all batch-size-one techniques, is "stop starting, start finishing". It recognizes that large amounts of work in progress (WIP) is a cost, not a benefit. It notes that 80% of the stories 100% done is far more valuable than 100% of the stories 80% done.
8. Inboard customer.
We bring an individual into the team, a maker just like the rest of us, whose specialty is "knowing what the customer wants". At its ideal, this is a literal customer. Weaker, but still useful, it is a "customer proxy". These people live with us, in-team.
There are many decisions, large & small, hinge almost entirely on the concepts of "what the customer would love, would hate, would live with". Inboard customers are our specialists in these areas. We turn to them to get just-in-time answers that tune our changes to our market.
9. Continuous deployment.
There are lots of variants of this idea depending on context, but the gist of it is: ship changes to the user as they are finished, and as a matter of course, semi- or even entirely automatically.
The driving idea is two-fold. First, that users perceive steady enhancement as a huge factor in value assessment. Second, that the only real way to "win" is by taking it to the field, and seeing whether it gets us what we wanted.
As you can see from this list, which probably isn’t complete, the three themes reach out and touch every practice, in whole or in part: collaboration, iteration, and confirmation. We could spend hours elucidating each of them.
Laying out the practices in a list like this can be misleading. These tend to be highly interdependent, and nary a one of them can be turned from level 1 to level 11 in a single move. Instead, we embrace change in another way: turn all the knobs a little, all the knobs a little.
I know few organizations that have viable implementations of all of these. Uptake is increasing, slowly but surely, these last two decades. As a software development coach, I’ll tell you, I have good days and I have bad ones. 🙂
But there’s a reason this change is so slow, a really good reason: "Embrace change" touches every aspect of our world as geeks. It’s in the tools, the techniques, the code, the teams, the process, the entire culture of geekery.
From that perspective, well, we’re doing well.
Supporting The PawCast
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. Support GeePaw Here.