PawCast with GeePaw Hill
149 episodes - English - Latest episode: over 1 year ago - ★★★★★ - 6 ratingsGeePaw is a software development coach with over 30 years in the field. His unique understanding of how to enact lasting change among teams has established him as a leader of the agility concept known as "Change-Harvesting". Here you can find his weekly podcasts.
Homepage Apple Podcasts Google Podcasts Overcast Castro Pocket Casts RSS feed
Episodes
The Pieces Premise | #97
December 08, 2020 11:00 - 8 minutes - 9.3 MBThe Pieces Premise says, "To get the whole thing to do what you want, start by getting each piece of it to do what you want. It's one of the basic underpinning of microtest TDD. The idea behind the pieces premise is actually pretty straightforward. All programs are divided into pieces, separate parts, each of which performs some behavior the program needs. If the pieces don't work, the whole won't work. I have seen a lot of struggling TDD efforts in my time. A great many of them start off we...
Collaboration, Complication, Continuity | #96
December 01, 2020 10:00 - 7 minutes - 13.5 MBI was recently asked, by two different groups, two seemingly different questions, but I gave them both the same answer: Collaboration, Complication, and Continuity. Let's mull that situation over. I spoke at a user group recently, on their choice of topic. They, ever so gently, pointed out that I'm old as dirt and have been a geek for forty years. And their question was how has programming changed since the caveman days of the '80s? In another part of the forest, I gave a university lecture ...
Old Coach at the End of the Bar | #95
November 27, 2020 10:00 - 5 minutes - 9.24 MBI am supposed to be shooting the next Real Programmer episode today, but I had a really good wrap-up meeting that was important, and I'm waiting for one more piece I need to send a first invoice to a new client, and I want to talk about coaching. In another part of the forest, some folks are discussing the frustrations of what is, by whatever name we call it, coaching. And the long and the short of it is "they won't even try what I want them to do". These sorts of conversations are pretty mu...
Change Harvesters Iterate Change | #94
November 24, 2020 10:00 - 8 minutes - 16.1 MBHuman, local, oriented, taken, and iterative, these are the change-harvester's bywords. In iterative change, we not only accept the reality of gradual stepwise refinement -- changing what we've already changed before -- we actually anticipate it and take advantage of it. With iteration, I think a great starting point for the concept is to watch just about any youtube video where a skilled artist draws a realistic rendering. What you will see almost inevitably is a direct implementation of it...
Change Harvesters Take Change | #93
September 25, 2020 09:00 - 7 minutes - 13.4 MBIn change-harvesting, we use this word "taken" in multiple senses, but to put it in a single sentence: the change-harvester takes both the substance of and the approach to change from what is already there. We *take* our changes from here, we don't *give* our changes to there. To go from A to B, it is easy to focus all of our attention on B. The change-harvester is saying we can't make effective changes unless we see them as *changes*, as transformations to A. And that implies paying a great...
Change Harvesters Orient Their Changes | #92
September 22, 2020 17:00 - 8 minutes - 15.3 MBLocality drives us to steps that are nearby, within our ready grasp, & therefore inherently small. But our *vision* isn't small, our program isn't, it's quite large. We can't get to it in one local step. How do we reconcile this? Oriented, taken, & iterative, each have an angle. Oriented is as simple as this: After every local step, we take a second and simply turn our selves back towards our distant target before we choose or take the next step. Humans are actually quite good at this. You d...
Change Harvesting Makes Local Changes | #91
September 18, 2020 09:00 - 8 minutes - 15.7 MBWe change-harvesters say human, local, oriented, taken, and iterative. We talked about human a couple of day ago, let's take on local. A quick sketch of the idea, and a couple of cases will do, yeah? When we say that we want our changes to be "local", what do we mean? I think in terms of two nearby metaphors, "neighborhood" and "reach". We want our changes to be in the neighborhood, and we want them to be in easy reach. Of course, "small" comes to mind right away, but it has its problems, mo...
Change Harvesting Emphasizes The Human | #90
September 15, 2020 09:00 - 7 minutes - 13 MBHuman, local, oriented, taken, and iterative: this is how change-harvesting in software development approaches change in most contexts in the trade. Let's take "human" today, and see where it leads us. When we use that word "human", change-harvesters are getting at the fact that, in systems involving humans, machines, and procedures, the humans are the most powerful force. When we seek change while ignoring human factors, we go awry quite rapidly. Human emphasis, in this usage, opposes both ...
The Cost of Rework Avoidance Theory | #89
September 11, 2020 09:00 - 8 minutes - 14.8 MBTo make the case for Change Harvesting as an approach, it's important to understand that the cost of Rework Avoidance Theory isn't imaginary or subtle, but both concrete & quite high. The most essential aspect of the RAT (Rework Avoidance Theory) is its emphasis on the endpoint: the City On The Hill we call it. The central concept: define the City rigorously, optimize building it off-line, move in to it only when it's done, and never change it again. In the RAT's idea of efficiency, changing...
CHT Means Different Design Imperatives | #88
September 08, 2020 09:00 - 8 minutes - 15.7 MBChange-harvesting software design centers "online" brownfield development: change-centric thinking. Most older sets of design imperatives are based in "offline" greenfield development: build-centric thinking. The differences can -- and should -- lead to design disagreements. The significance of "online brownfield" vs "offline greenfield" is hard to overstate, in all areas of software development, but especially so when we talk about what makes a design "good" or "bad". In four decades, I've ...
Human-less Change Fails | #87
September 04, 2020 09:00 - 6 minutes - 11.7 MBA lot of the reasons that change fails, inside & outside technical organizations, come down to one broad statement: the people who have to make the changes are humans, and the people who want them to make the changes have not successfully taken this into account. People ask me why the change they're trying to make doesn't happen. The questions come from all levels of an org, from the very top to the very bottom. "Why won't they change?" It's often accompanied by an implicit theory. It's ofte...
CHT-Style Implementation | #86
September 01, 2020 09:00 - 8 minutes - 16.4 MBWhen we did our compare & contrast of the working models underpinned by Change-Harvesting theory (CHT) vs Rework Avoidance Theory (RAT), we temporarily sidestepped the specific differences of the implementation part. Let’s drill in on that today. It was quite a sidestep: other than the implementation part of the two models, they have much in common, with the key difference being the highly iterative nature of CHT’s approach. If we squint a little, & we don’t talk implementation, we can see t...
Change Harvesting vs Rework Avoidance | #85
August 28, 2020 09:00 - 9 minutes - 16.6 MBLet's compare and contrast the RAT (Rework Avoidance Theory) model of software development with the CHT (Change Harvester Theory) model. The differences are multiple and pronounced, so this may take us a while. I want to talk not so much about the theories today, as about the working models they underpin and lead to. Those models are a kind of inner core of making software, shaping our activities of course, but also our solutions, and even the problems. The RAT model sees software developmen...
Iterative User Value in Flows | #84
August 25, 2020 09:00 - 6 minutes - 11.3 MBA flow app, one that steps the user through an acyclic graph, typically gathering info at each stage, can be built to provide iterative user value by gradual refinement. Let's look at how that's done. The standard flow app is when we walk the user through a complex operation, and we gather the pieces step by step. Though it looks like a straight line to any given user, the answers in previous steps actually shape the following steps, hence the directed graph under the hood. In most web envir...
The Correlation Principle | #83
August 21, 2020 09:00 - 10 minutes - 19.6 MBThe correlation principle says that our productivity is tightly correlated with the internal quality of software. The two go up together, and they go down together, and you can't trade away the one to get more of the other. The basic idea of the correlation premise is actually pretty simple, but when we introduce it, we generally get a chorus of yabbits. ("Yeah, but...") There are several confusions common to most of that chorus, so let's look at them one at a time. Confusion: mixing up inte...
Iterative User Value | #82
August 18, 2020 09:00 - 9 minutes - 16.5 MBHow do we iterate user value? How can we follow the "more smaller steps" approach and still deliver a positive experience for the user? Today let's look at some ways to approach this problem. The problem. We want our work to come in stories of about one team-day and a half, but that's not much time, and we need to provide a steady flow of value to our users. The truth is, most of us have been trained away from even *trying* to do this. It's no wonder it's not obvious how to do it now. I want...
Pathing: A Style of Laying Out Work | #81
August 14, 2020 09:00 - 7 minutes - 13.2 MBI do “pathing” when I project my work into the future: laying out a sequence of work steps, where each step ends with the code in a shippable state. More than design, and more than planning, pathing is a kind of work-style, and it brings me several benefits. When we're pathing, we're really just decomposing a problem, breaking it into several smaller problems. What makes me call it pathing -- instead of design or planning -- are two requirements we want each sub-problem to meet before we're ...
Embrace Change: Modern Geekery Practices | #80
August 11, 2020 09:00 - 8 minutes - 16 MBWe *change* software, therefore we want everything around us to support that: code, technique, tools, controls, tracking, planning, infrastructure, and above all, culture. 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 ar...
Pedagogy In The Trade: Changing Emphasis | #79
August 07, 2020 09:00 - 9 minutes - 17 MBI want to start talking about teaching in the geek trades. Today in particular, I want to talk about "emphasis", what our style & materials stresses or underlines about the path to mastery for our up and coming geeks. I am by nature an analyst, a theorist, and a person driven to critique. That makes me pretty negative-seeming at times. That's not accidental. I find that I often can't find a way forward until I have thoroughly identified what I don't like about where I am now. Of course, whil...
Retrospectives: Variety Is Key | #78
August 04, 2020 09:00 - 8 minutes - 16.2 MBI strongly recommend high variation in both format and facilitator of retrospectives. So let me sketch, as quickly as possible, the retro-scheme I see the most of, and don’t care for. It’s got four columns. "Didn’t go well". "Went Well", "Action Items", "Kudos". Sometimes they change the text of the columns. One person, the same person each time, leads the meeting, by gathering stickies, virtual or otherwise, and plunking them on a board in the right column. That person typically groups the ...
TDD Tests Are First-Class Code | #77
July 31, 2020 09:00 - 9 minutes - 18 MBMy standards for TDD microtests are the same standards I have for shipping code, and I follow them in microtests for the same reason I follow them in shipping code: they make me faster. I go out in the field, and I inspect a lot of tests, and I have to say, lousy factoring, bad naming, massive duplication, and low signal-to-noise are pretty much the order of the day out there. This often holds true even when the shipping code is comparatively well made. I suspect a lot of this comes from the...
Re-Balancing Made, Making, and Makers | #76
July 28, 2020 09:00 - 9 minutes - 16.8 MBSome 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. 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 de...
Microtest TDD is Gray-Box | #75
July 24, 2020 09:00 - 10 minutes - 19.9 MBIn the '70's, an important movement developed in testing theory, called "black box" testing. The idea is straightforward: We can prove our software works by treating it as a closed opaque container with only some knobs and meters on the front of it, a "black box". The tests we write don't know what 's inside the box, they only know the specification of how the surface controls are supposed to work. If they don't work tht way it's a fail, if they do work that way it's a pass. This idea has gr...
Understanding Incremental Switchover | #74
July 21, 2020 09:00 - 10 minutes - 18.8 MBThe incremental switchover approach is my default response to any transformation problem I can't resolve in an hour. It's the secret to successful brownfield development, but it's not widely understood & used. Let's take some time to understand it. Incremental switchover might be called "the art of the path". At its simplest, given two points A, where we are, and Z, where we wish we were, incremental switchover concerns itself with B, C, D, and so on, the route we take. We talked about RAT a...
The RAT: Rework Avoidance Theory | #73
July 17, 2020 09:00 - 8 minutes - 16.4 MBRework Avoidance Theory is a cluster of related ideas seeing a change as having a clear start-point & end-point and a straight & stable path between them. It draws its inspiration largely from logic based in relatively straightforward metaphors to the physical world. One metaphor is that of a footrace. The change is a well-marked track with one runner. It assumes 1) linear cost of step regardless of size, 2) stability and perfect knowledge of path and endpoints, and 3) indifference to post-f...
Turning Implicit into Explicit | #72
July 14, 2020 09:00 - 9 minutes - 17 MBAn implicit understanding is anything a skilled geek would have to be told before being set loose in your codebase to make a change. Implicit understandings take lots of different forms, but at their simplest, they often involve hidden correlations. Probably the most common form of implicit understanding is related to the smell we call primitive obsession. You'll see a series of methods, and each method takes the same three arguments, an int for the ID, a string for the descriptor, and a dec...
Model-View, The Desktop, and TDD | #71
July 10, 2020 09:00 - 11 minutes - 20.1 MBThe basic idea behind all Model/View schemes, and there are several of them, is just this: draw a thick line between what your program does and how your program shows what it does. In other words, it's a compositional heuristic, guidance for how we break our problems into smaller problems. Give some objects/modules the responsibility for doing the work, and give other objects/modules the responsibility for showing the work. Tho it was originally conceived in the smalltalk world, there are ma...
Helping Your Downstream Collaborators | #70
July 07, 2020 09:00 - 8 minutes - 15.1 MBLet's talk about ways to make life easier for downstream developers, be they front-end or dependent back-end people. Whether you have a bunch of front-end folks driven from your monolith, or you live in service-mesh land with dozens of microservices, the people downstream from you have to use your output to make their output. They are, in fact, a kind of customer. We've talked at some length about the Made, the Making, and the Makers, and how the trade is normally over-obsessed with the Made...
Helping Your Downstream Collaborators
July 07, 2020 09:00 - 8 minutes - 15.1 MBLet's talk about ways to make life easier for downstream developers, be they front-end or dependent back-end people. Whether you have a bunch of front-end folks driven from your monolith, or you live in service-mesh land with dozens of microservices, the people downstream from you have to use your output to make their output. They are, in fact, a kind of customer. We've talked at some length about the Made, the Making, and the Makers, and how the trade is normally over-obsessed with the Made...
Metrics and Three Traps
July 03, 2020 09:00 - 6 minutes - 11.9 MBIn twenty years of coaching software development teams, I've seen maybe a hundred or more orgs try to figure out how to measure their process, and the majority of them have fallen into some mix of three traps: 1) the more trap, 2) the objectivity trap, 3) the rollup trap. Years ago I heard the non-standard saying that "the road to hell is lined with great parking spaces". I see these traps that way: they seem to suck us in more or less thoughtlessly, and once in them, we seem to fight noisil...
Metrics and Three Traps | #69
July 03, 2020 09:00 - 6 minutes - 11.9 MBIn twenty years of coaching software development teams, I've seen maybe a hundred or more orgs try to figure out how to measure their process, and the majority of them have fallen into some mix of three traps: 1) the more trap, 2) the objectivity trap, 3) the rollup trap. Years ago I heard the non-standard saying that "the road to hell is lined with great parking spaces". I see these traps that way: they seem to suck us in more or less thoughtlessly, and once in them, we seem to fight noisil...
The Right Step | #68
June 30, 2020 09:00 - 8 minutes - 15.1 MBA lot of folks spend a great deal of time arguing about which step is the right step. A change-harvester would say to stop worrying about this so much. The right step to take is 1) small, 2) not definitely backwards, and 3) not the last one. Let's take up "not the last one". A lot of thinking about change comes with the baked-in idea that there will be an end to it, a "finish line", if you will. We will make a change, or some changes, and in so doing we will cross a finish line, after which ...
More on Small Steps | #67
June 26, 2020 09:00 - 6 minutes - 11.9 MBThe single most important thing my years of doing XP helped me learn, specifically TDD and refactoring, is about the size of the steps. When I started it, I had in mind “small steps” that were, well, they weren’t really small at all, just “comparatively less gigantic”. Graybeards like me came up a certain way. We relied heavily on 1) large and well-organized memory, 2) a facility for rapid transition back and forth between high-structured high-detail imperative text and ordinary meaning, 3) ...
Pull & Swarm | #66
June 23, 2020 09:00 - 8 minutes - 15.5 MBPull & Swarm is a technique for approaching the workload in front of a small team. It amounts to pulling one story from our queue at a time, and throwing all of our resources and humans at the same story at the same time. P&S can be useful to Scrum-based teams, but also to any small team using any method. Some teams I have worked with have done *pure* P&S. No planning as a group at all, no ceremonies, just make a queue with a half-dozen things in it, pull one, finish it, on to the next. But ...
Microtest TDD: Economics | #65
June 19, 2020 09:00 - 8 minutes - 14.8 MBThe economic aspects of microtest TDD are inextricably tied to the operational aspects of it. If we concentrate only on the artifacts involved, we will lose the picture and misunderstand the value proposition. As a professional geek, the heart of my job is changing rigidly structured imperative text in collaboration with other humans, in order to meet a variety of locally or temporally aligned goals. That's fancy talk for "I change code, in community, for money." The central event is the *ch...
Hitting On Speakers (Rant-y) | #64
June 16, 2020 09:00 - 6 minutes - 11.9 MBI want to talk about this thing where you see someone on stage/screen presenting material about geekery, you decide you're attracted, and you send them mail or dm hitting on them. You must not do this. It is rude, unprofessional, and hurtful to many people. Stop it. --- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter, or drop a voice message via the voice messages link here on Anchor. If you are intere...
Microtest TDD: More Definition | #63
June 12, 2020 09:00 - 7 minutes - 13.1 MBWhat's a microtest, anyway? I write a ton of tests as I'm building code, and the majority of these are a particular kind or style of test, the microtest kind. Let's talk about what I mean by that, today, then we'll talk later about how that turns out to help me so much. A microtest is a small, fast, precise, easy-to-invoke/read/write/debug chunk of code that exercises a single particular path through another chunk of code containing the branching logic from my shipping app. Microtests are fi...
Microtest TDD: The Big Picture | #62
June 09, 2020 09:00 - 5 minutes - 10.4 MBI think of my style of coding as "microtest TDD". That can be misleading for folks, so let's take a walk over a few of the ideas, implicit and explicit, that make up the approach. First things first, bear the money premise in mind in all that follows, to wit: "I'm in this for the money." In the software trade, we make money by shipping more value faster. This is why I adopt these practices, because when I do them, I go faster. In particular, I don't do them out of a fondness for artistry, in...
The Jump To Microservices | #61
June 05, 2020 09:00 - 4 minutes - 8.77 MBMore seriously, the first piece of advice I'd give a monolith-owner about converting to microservices would be to work very hard to factor their monolith well. Interestingly, across dozens of cases, I've never seen that advice taken. There's always a well-dressed person with excellent powerpoint who is happy to give a compelling case for a technical solution to a problem that isn't technical. If you can't factor the monolith, you won't be able to factor your microservices. All of the same fo...
An Intro to Spikes | #60
June 02, 2020 09:00 - 9 minutes - 17.4 MBI use spikes, periods of code-changing activity that end with no pushes, all the time, at small scale and large, as a way to develop my path. It's a vital technique, and it's often underplayed, so let's spend some time with it. What's a spike? A spike is a stretch of time I spend mucking about in code, and that stretch of time has one rule: "Do anything you want, because you can't keep it." We originally used the term to describe a certain kind of story. We'd be facing some task without the ...
Steps, Value, and Change-Harvesting | #59
May 29, 2020 09:00 - 10 minutes - 20 MBLet's talk about steps and value. Out in the world, folks make a lot of decisions involving these ideas, they reason about them. We want to make sure our reasoning is based on a thorough understanding of the implicit premises. What's a step? A step is a gap or space, in time and activity, in between two points, a Before point and an After point. At the Before point, a system is "ready". At the After point, a system is "ready". In between, during the step, the system is "unready". That idea, ...
My Best Bug | #58
May 26, 2020 09:00 - 6 minutes - 12.1 MBI shipped a word processor that formatted the hard drive every 1024 saves. Must have '84 or '85. I was a bright 25-year-old with about five years in the game. I was one of two programmers who wrote & maintained a suite of apps kinda like Office: spreadsheet, wp, database, plotter, such like. We customized everything for three or four vertical markets. So I wrote most of the wp. This was in Forth, on a variety of OS/CPU combinations. Young'uns don't necessarily know this, but in those fays th...
Juniors & Seniors | #57
May 22, 2020 09:00 - 7 minutes - 12.9 MBLotta inspiration for junior geeks stuff floating around. I'm having a low productivity day today because, well, you know all of that, so I'll take a minute nd pitch in. Do you know what I did for about twelve elapsed hours of coding time? I solved a problem. Cuz, you know, I got mad skillz, and have been geeking for forty years, and am even, in a couple of microdomains, a bona fide citable expert. I'll tell you the problem I solved, next tweet, but before we take the dive, I need you to jus...
Using the Strategy Pattern | #56
May 19, 2020 09:00 - 9 minutes - 18.2 MBThe strategy pattern lets you make "pluggable algorithms", so clients have different behavior without having different code themselves. We often use it to capture the "consequence in code" of some condition, which we can then let other code use without re-testing the condition. Here's a little java snippet: dimension = horizontal ? width : height If you're not familiar with ternary operations, what this says is "if horizontal is true, use the width, otherwise use the height". That snippet ...
Dealing with Nulls | #55
May 15, 2020 09:00 - 9 minutes - 18 MBAnother refactoring topic today: dealing with nulls. There are a bunch of techniques, but they amount to a) don't, and b) do but only one time ever. The basic idea: a null always occurs in a particular context, and in that context, it has a meaning. When we pass it up or down our call-stack, we are *changing* contexts, and hence changing meanings. We're using the same symbol to mean different things at different times. Using the same generic symbol to mean different things in different conte...
Refactoring Strategy: Move It Where You Can Test It | #54
May 12, 2020 09:00 - 7 minutes - 14.3 MBWhen I can't test it where it is, I look to move it somewhere else, where I can test it. Today's notion isn't so much a single refactoring as it is a strategy that can be achieved in different ways (and different multiple steps). A modern and frequently occurring case: using a cool framework to expose service endpoints, we write a function and then we annotate it and poof, it's an endpoint. This is how Java+Swing works, or Python+Flask. When we give that function a body, it will be a body of...
Refactoring: Invert Dependency With Observer | #53
May 08, 2020 09:00 - 10 minutes - 19.7 MBAnother refactoring today: Use the observer pattern to invert an infelicitous dependency. In and of itself, this is a modest refactoring, but its smell often co-presents with others, and unravelling it all can be tricky. (Note: We aren't remotely done talking about first and second-order refactorings, there are plenty more to go. But I'm not writing a catalog, I'm working a project, so when a hefty one like this comes along, that's when I'm talking about it. You're gettin' em as I'm doin' em...
Refactoring: Demeter-Wrapping | #52
May 05, 2020 09:00 - 7 minutes - 13.9 MBDemeter violations are places where a client accesses not just an upstream service, but that service's upstream services, or even that service's service's upstream services. It's a common problem in evolving code, and left untended, a classic source of unchangeable code. Demeter calls look this: a.getB().getC().doSomething(). a is getting a B, but is using that B expressly to get a C, then finally calling some method on the C to do something. (The getX()'s could as easily be exposed fields r...
Refactoring: Keep It Running | #51
May 01, 2020 09:00 - 6 minutes - 11 MBA key value for those who take up the change-harvesting approach: "keep it running". This is actually a direct result of human, local, oriented, taken, iterative, and argues against many finish-line efficiency approaches. Think of a change as a point A, with an arrow coming out of it and ending at a point B. At the two points, we have a running system, but along the arrow, we don't: our change is in flight. The change-harvester seeks to keep those arrows as short as possible. I say seeks, bu...
Chunking & Naming | #50
April 28, 2020 09:00 - 7 minutes - 14.6 MBIn our continuing conversation about refactoring, I want to go a little abstract today, and talk about chunking and naming. Naturally, a topic this important has already been addressed by a stupid joke in the movie Airplane!, so we'll start there. A passenger is approached by a steward, asking if he might be able to help with a problem in the cockpit. He says, "The cockpit! What is it?". She says, "It's the little room at the front of the plane where the pilots sit, but that's not important ...