PawCast with GeePaw Hill

GeePaw Hill

GeePaw 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.

mwp.podcast.all.episodes

We've covered the MMMSS idea a couple of times now. This time we want to consider the key element of the case in favor: the remarkable intrinsic value we receive from Many More Much Smaller Steps. It's not immediately obvious, so let's take our time. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

9 nov.

time.minutes.short time.seconds.short

As a person who has been successfully coaching software development teams for twenty years, let me throw out a few ideas to chew over. With luck, maybe one of them will jiggle the frame enough for you to find a next step. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

2 nov.

time.minutes.short time.seconds.short

Earlier, we sketched out MMMSS, Many More Much Smaller Steps, laying out the bare bones. Cool, cool, but now we need to thicken our sense of the idea. Today, let's close in a little more on what "step" means to us. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

26 oct.

time.minutes.short time.seconds.short

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 isn't gonna happen in one thread, but let's get started. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

28 sep.

time.minutes.short time.seconds.short

In the spirit of my Ten I-Statements about TDD, here's ten more, this time about refactoring. I'm not covering everything, just hitting some of the high points of my refactoring activity here. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

17 ago.

time.minutes.short time.seconds.short

Programmers will ask me how they can become stronger at programming. A very good way, one I use currently, is to get together once a week with a handful of geek friends of varying talents, interests, and projects, for a casual geekery-sharing session. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

10 ago.

time.minutes.short time.seconds.short

Folks, I see a lot of ideas and opinions about TDD fly around, passed off as holy writ. By way of counter, I offer you Ten I-Statements About TDD. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

3 ago.

time.minutes.short time.seconds.short

Coaching Pro-Tip: Don't fall -- or get pushed -- into the trap of being responsible for a team's targets. Your mission as a coach is to care for the health of your team, it's not to hit a deadline. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

13 jul.

time.minutes.short time.seconds.short

Coaching Pro-Tip #1: Everything good about agility is rooted in relationship, so everything good about coaching is, too. As coaches, we usually start from negative trust, and our central priority has to be reversing that position. Coaching Pro-Tip #2: When the developers act like testing the code is a time-wasting checkbox that costs a great deal and rewards very little, they are usually right, and one has to find out why, and tackle that, before pressing them to test more. Coaching Pro-Tip: Sometimes it's just chemistry. One advanced coaching skill is understanding when you're not some team's cup of tea, and seeing when the right thing to do is help them find someone they can relate to. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

6 jul.

time.minutes.short time.seconds.short

Two recurring phrases in my work are 1) It is like this because we built it to be like this. 2) The code works for you, you don't work for the code. Two sides of one page, phrased on the front as negative critique, and on the verso as positive encouragement. -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

15 jun.

time.minutes.short time.seconds.short

"Path-focused design", of stories, architecture, code, is design that understands that we can only reach a distant City on the Hill by taking one stride-limited shipping step at a time.  -- You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! -- --- Send in a voice message: https://anchor.fm/geepawhill/message

25 may.

time.minutes.short time.seconds.short

Big-batch releases, coordinated and controlled by a central intelligence, fail, and fail frequently. Several aspects of this are fascinating, because of the interplay of hard mathematical reality with human frailty. Let's take a swing. - You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack!) --- Send in a voice message: https://anchor.fm/geepawhill/message

18 may.

time.minutes.short time.seconds.short

You can put all your configuration in a shared library and eliminate just about every mis-configuration in your multi-process application. It's not free, but it's cheap, and it kills a lot of minor pain. Let's take a gander. You can read the full transcription of this podcast over on GeePawHill.org. Any feedback, you can always tweet @GeePawHill on Twitter. To get more involved in the Change-Harvesting community, click here to join the Camerata Slack! --- Send in a voice message: https://anchor.fm/geepawhill/message

11 may.

time.minutes.short time.seconds.short

When large teams struggle with trunk-based development (TBD) or continuous integration/deployment (CI/CD), a good strategy is to re-orient how the teams face "backsteps", moments in our workflow where a discovery forces us to re-open a stage we thought was closed. Large teams & projects often pre-date the use of modern synthesis techniques like TBD or CD, and during adoption, intermixing their Before with this new After can produce quite a bit of discomfort. If it gets bad enough, it can even kill off the improvement effort. What to do?  --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

4 may.

time.minutes.short time.seconds.short

A couple of days back, I tweeted about SAFe. It created some stir on the timeline, which was great, as I got to see a lot of perspectives. I want to use that tweet as an excuse to talk about something much larger. This will be a long one. :)  --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

27 abr.

time.minutes.short time.seconds.short

The standup is a short recurring meeting used to (re-)focus the team-mind on effectively moving stories through our workflow. Here's my recommended approach to having standups be useful and brief. The general sequence is 1) address team-wide emergency issues, 2) work story-by-story, 3) distribute new work, 4) address team-wide non-emergency issues. Note that, quite often, there is no part 1, and no part 4. Sometimes there's not even a part 3. Some general tips, then: --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

20 abr.

time.minutes.short time.seconds.short

The ultimate making app for a shipping multi-service system is actually a one-machine monolith with a UI. If your team is experiencing the most common pains from working in a large SOA environment, the productivity payback will be enormous. We've talked a lot about the idea of having a shipping app for our customers and a making app for us. We can use the same source base to make multiple binaries. We target customer needs with one of those, and we target developer needs with the rest. The economics of this approach are straightforward: As long as a making app's benefit — improved productivity on the shipping app — is less than its cost — the time spent working on something we don’t ship — we get a net gain in productivity. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

13 abr.

time.minutes.short time.seconds.short

My rice'n'garlic advice, "take many more much smaller steps," can be said another way: reject any proposed path that requires a step size larger than the limit you've set for that particular domain of activity. "Rice'n'garlic advice" is blind advice, for when people ask you what to do, but you're not there & can't see. You have to guess. A professional chef I know, when asked to give blind advice, always says this: 1) That's too much rice. 2) That's not enough garlic. This kind of advice isn't expressing a universal law. (It is difficult to do, but you *can* have too much garlic, after all.) Nevertheless, for most people doing the asking, most of the time, that's a pretty good hipshot, applicable to most of her actual audience. My blind advice, in that same spirit, is this: Take many more much smaller steps. It's not a universal law. It's just a shot from the hip, and I find it's generally good advice, for most of the people asking, most of the time. Here's how it works. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

6 abr.

time.minutes.short time.seconds.short

Once armed with the idea of a shipping app and a making app, a whole range of possibilities open up. Among the most powerful: give your making app a UI just for making. A "making app" is when we take the same sourcecode from the program we're shipping, and use it for another program at the same time. That program is one we develop and tailor expressly to enable us to work more effectively on the shipping app. We tend to overlook it, but when we run our unit tests, for instance, we're actually running a making app. Whole great swathes of the code are exactly the same code we ship, just put together in a different way. But there's no reason to have just one making app, and no reason to limit its capability to only running our microtests. We can do all sorts of cool things in a making app. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

30 mar.

time.minutes.short time.seconds.short

In a data-rich environment, we can use the Builder concept to make DSL's for our Making application. This often makes testing the hard business core of our code both faster and easier. We've spoken in the past about using our codebase to do more than one thing. We always use it to create our shipping app. But we can and do use it for an app that improves our *making* process. We call that the making app. When you're running your microtests, it doesn't necessarily look or feel like you're running an app, but you are. And that app uses much of the same source-code that what you ship does. It just uses it in a very different way. Some applications manipulate a whole lot of intricately connected data. In the world of healthcare, for instance, an app might have literally dozens of classes, all rooted to and connected with a Patient. And the business logic is quite thick, with many cases and variants. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

23 mar.

time.minutes.short time.seconds.short

Approaches in software development -- or anything else -- that don't take ordinray human failings as their starting point are prone to dramatic failure. "The Impossible Human" is, well, noticeably uncommon. Let's dig in on that. Some years back, I made content for a CMS that had a whole lot of overlapping parts, each with its own special language. I found it very difficult to express myself quickly & cleanly, and, it being me, I complained about it a lot. And very often, the responses I received were in the form of "It's easy, just remember X." It still being me, I became sullen and resentful, and was largely unproductive for long stretches. "It's easy, just remember these 371 simple rules" is a formula for disaster, because it's an approach based on "The Impossible Human". Ordinary humans don't remember 371 simple rules about anything they haven't already mastered. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

11 mar.

time.minutes.short time.seconds.short

"It puts the database on its browser skin, or else it gets the hose again." This task occupies the daily life of a great many programmers. Today, I want to throw out some random sparks of advice for people working in that setting. In enterprise IT, it is commonplace for backend folks to work on problems shaped like this: there's a web endpoint controller on the top, a database on the bottom, and some simple or complicated business logic in the middle. I watch people working in this kind of environment quite a bit, and I have to tell you, most of what I see is them having a lousy time doing boring work in a tedious and time-consuming fashion. These ideas I want to toss at you are something of a grab-bag. They're just little seeds, not worked out answers, but my goal in offering them is to jiggle a mind or two: to get folks thinking about how they could do this kind of work in a way that *wasn't* a boring drag. And I spoze that's the meta-seed: "You don't have to live like this." --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

3 mar.

time.minutes.short time.seconds.short

When we talk about transitioning to microtest TDD, we have to figure out how to provide the right experiences in the right order. That's why I propose we start by getting the experience of changing a well-microtested graceful class. "Create Experiences, Not Arguments" is one of the core habits of change-harvesters. We want to take that slogan very seriously when we approach any significant change to our practice. And microtest TDD, believe me, is a significant change. A would-be TDD coach or instructor nearly always carries an implicit belief that her victims do not have, drawn from lived experience that they don't have. It is this: "What we are doing now is much more unpleasant and unproductive than what we'll be doing when we TDD." --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

23 feb.

time.minutes.short time.seconds.short

Microtest TDD is a "way of coding", not an after-market bolt-on to old-school approaches, and as a result, we have to constantly intertwine our conversation about technique with our conversation about transition. Technique, skills, philosophy, theory, all of these are tremendous delights to me. I love to muse & mull & illustrate & analyze & argue & point, and I greatly enjoy doing it on the topic of the modern synthesis in software development. But all of this explication & analysis is about a framework of related ideas. And that body of knowledge is a "there", a point on the time horizon we can orient towards. We, the trade, well, we're "here". How do we move from here to there? Because it doesn't matter what color the walls are painted in the City on the Hill if we can't find a path that takes us toward 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

16 feb.

time.minutes.short time.seconds.short

In microtest TDD, we describe collaborations as "awkward" or "graceful". The distinction is critical to understanding how the Steering premise and the Pieces premise work together to make TDD a productivity tool. Let's dig in. We talked the other day about understanding & manipulating dependency in microtest TDD. The awkward/graceful distinction is at the heart of this. It can be a long journey to get it all, but it *starts* as soon as you take TDD for a spin in your day job. To get into this, let's take two classes most of us are familiar with: String and File. (I'm thinking in Java, but I suspect much of what we see will apply in most languages.) String is graceful. File is awkward. Let's see what that means. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

12 feb.

time.minutes.short time.seconds.short

Successful microtest TDD depends on our ability to solve a goldilocks challenge: when we test our code pieces, do we isolate them too much, too little, or just right? Finding the sweet spot will mean letting go of rulesets & purity. The five premises we've been over: value, judgment, correlation, steering, and pieces, guide us in a complicated dance of software design. At the center of that dance is our awareness of -- and our manipulation of -- "dependency", how one part of the code uses other parts of it. From the moment you wrote your first program, you produced a high-structure high-detail text that *depends* on the output of other high-structure high-detail text. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

9 feb.

time.minutes.short time.seconds.short

Because microtest TDD is more a "way of geeking" than a technique or a received body of knowledge, building one's faculties is a long and sometimes perilous effort. Let's talk about learning. I want to approach the question(s) of learning TDD in some ways that are a little different from others I've seen. I've written two TDD curricula myself, and am involved currently in helping with two more. I see all of them, including the current ones, as "interesting failures". At first, learning/teaching TDD seems like a road, then over time it seems to become a tree, and ultimately it feels much more like a spreading activation network, including lots of external triggers, plateau periods, and transformative experiences. (I'm open to the possibility that this is what *any* judgment-centric skill looks like, but for now I just want to talk about TDD.) --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

5 feb.

time.minutes.short time.seconds.short

Microtest TDD is an effective change strategy because it dramatically improves our performance at comprehension, confirmation, and regression detection, all critical factors in handling change quickly & safely. We've covered a lot of ground in considering TDD recently. The five premises, the need for a change strategy, the increasing collaboration, complication, and continuity of modern software, and some high-level less-obvious aspects of the practice itself. I want to put some of these pieces together, and show you how TDD adds up to an effective change strategy. It doesn't "boil down" very well: as with most conversations around complex systems, the effect is multi-sourced and multi-layered. This may take us a little while. :) --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

2 feb.

time.minutes.short time.seconds.short

I got one of those messages I sometimes get from a reader, telling me that including my politics in my muses/blogs is off-putting. As a general rule, I don't bother to respond to these. I gain and lose followers all the time, everyoen who makes content does, for all sorts of reasons, and that's just one more. Today, though, surrounded by all of this, I feel like I want to give a more full statement on the matter. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

29 ene.

time.minutes.short time.seconds.short

Before we can make the case that microtest TDD is an effective change strategy, there's a few high-level aspects of it that we need to highlight. We tend to take these for granted in our case, but newcomers won't already know them. Today, I'm writing for the newcomer. It's going to be a little rambly, because the ideas aren't partitioning a single conceptual level into its component parts. Think of me as going over a text with a yellow highlighter, bringing out some points newcomers might not readily see. Twinning: When we do TDD, we are working in a single textual codebase that we use to produce two entirely separate applications, each serving a different purpose. The one app will be the one we ship. The other app will be a primary tool for producing the first app more quickly. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

26 ene.

time.minutes.short time.seconds.short

Microtest Test-Driven Development is a strategy for *change*. To understand the case, we need to answer two questions: 1) Why have a strategy for change? 2) How does TDD provide one? Let's take up the first question today. Why is having a change strategy so urgent? The TL;DR is dead simple: Because continuous ongoing change is at the base of all software development, both before and after our software is in the field. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

22 ene.

time.minutes.short time.seconds.short

Today it's microtest TDD's Value Premise: TDD ships more value faster when that value depends on changing our branching logic safely & quickly. Let's dig in. I am frequently presented with declarations that TDD is fine for plebs like me, but useless for software of type X. I've heard every variety of app type or coding specialty or domain substituted for that X. In other parts of the forest, I hear that the purpose of TDD is high quality, and if you don't care about that, you don't need TDD. Or that it's for satisfying personal or professional ethics, and if you don't care about that you don't need TDD and you're a bad person. The Value premise says that TDD is an instrument for productivity, and its effectiveness depends on how much of our work requires us to change our branching logic, which it lets us do with greater speed and lower risk than non-TDD methods. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

19 ene.

time.minutes.short time.seconds.short

Today, let’s take on microtest TDD’s Correlation Premise: Internal software quality (ISQ) and productivity are directly correlated. They go up together, and they go down together. The correlation premise lies in direct opposition to the widespread but grossly over-simple analysis that suggests we can “go faster” by shorting the internal quality of our code. It says, on the contrary, the lower that internal quality, the lower our productivity. Start by noting that we’re talking about internal software quality (ISQ), not external software quality (ESQ). What’s the difference? ISQ is the attributes of the program that we can only see when we have the code in front of us. ESQ is those attributes a user of the program can see. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

dic. de 2020

time.minutes.short time.seconds.short

Today, let’s talk about microtest TDD’s Judgment Premise: “We are absolutely and permanently reliant on individual humans using their individual judgment in TDD.” The judgment premise emphasizes the human in test-driven development. There are no known non-humans practicing TDD, so it may seem a odd that we have to talk about this, and yet, we do. As software geeks, we work with the most rigid deterministic systems conceivable, and we do much of that work in abstract mental space. To say that our target systems are machine-like is to say too little, really: they’re more machine-like than any real-world machine. The uber-mechanical material of our job can lead us to seeing every aspect of the job as if it were the same as that material, a phenomenon the French call “deformation professionelle”. Put simply: working with uber-machines all day, we imagine uber-machines everywhere. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

dic. de 2020

time.minutes.short time.seconds.short

Microtest TDD's Steering Premise is quite simple, which may be why it sometimes meets furious opposition. It says "Tests and testability are first-class citizens in design." Let's talk that over a little. There are, for any software problem, an infinite number of functionally correct designs. If implemented, they will work. But we don't *implement* an infinite number of designs. Why not? Because though they may be functionally correct, they still don't fit our context. We reject designs -- more often we reject individual choices in designs -- for a variety of reasons: reliability, cost of hardware, poor fit to our toolset, and so on. Those reasons are the "citizens" of the design process. And the steering premise says that one of the citizens -- not a secondary or minor or ex post facto consideration -- is whether that design can be tested. To probe at it: If you brought us a functionally correct design that required our app to run on a million AWS instances, we'd casually say "no, that's not valid." So obvious is this conclusion, that no one ever does it. Designs don't even get that far with such an issue. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

dic. de 2020

time.minutes.short time.seconds.short

The 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 well and end poorly, and it's very often because the Pieces Premise is not sufficiently understood by the would-be practitioners. Imagine a class. (Or a function, or a subroutine, or a module, or whatever level of decomposition you use in your environment.) Let's call it S, for "Simple". Its guts use only basic logic and primitives from your language. Classes like this are what we start nearly all first-time TDD'ers on. You write a test, you make it pass, you design it optimally. Rinse, lather, repeat. And when you do this, I'll be damned, you find that TDD is pretty cool. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

dic. de 2020

time.minutes.short time.seconds.short

I 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 last month, and because I was the industry expert, one of the speaking prompts they gave me was, my words not theirs: "What's the difference between the pro game and the college game in the sport of geekery?" Maybe to you those two questions seem obviously "the same", but to me they seemed very different. After all, I didn't start out in geekery as a college student, but as a (weak but enthusiastic) pro. I didn't graduate from college, and in any case didn't study programming there. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

dic. de 2020

time.minutes.short time.seconds.short

I 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 much standard "coaches-at-the-bar" talk. After all, getting people to try things we want them to is pretty much the job. All jobs are like this. I can't imagine what my doctors, quaffing an icy one after work, say about *me*, for instance. "This idiot spends his entire adult life ignoring every aspect of his body's needs, and he won't even *try* taking a fifteen-minute walk every day. Now he whines at me all the time cuz his back hurts!" And so but anyway, you know what? Today, I'm that old doctor who sits down at the far end of the bar, sipping his scotch, watching Jeopardy, and occasionally throwing out some snarly annoying meta-commentary. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

nov. de 2020

time.minutes.short time.seconds.short

Human, 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 iterative change. The strokes begin quite broadly, faintly indicating the broad contours of the subject. Experience is relevant here: those who are most familiar with drawing that particular kind of subject, will make contours that seem "right" more quickly than those less experienced. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

nov. de 2020

time.minutes.short time.seconds.short

In 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 deal of attention to what that A is and how it works now. Although "taken" may seem a little shaded or obscure, it's actually at the very center of what it means to change a thing, as opposed to building one. We've touched many times on the difference between greenfield & brownfield. With taken change we see that difference in action. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

sep. de 2020

time.minutes.short time.seconds.short

Locality 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 do it when you cross a busy road. There, it happens so quickly you hardly notice it. More consciously, you do it when you navigate to your vacation or tourism spot. Take a step, face the landmark, take a step, face the landmark. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

sep. de 2020

time.minutes.short time.seconds.short

We 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, most notably that it almost immediately prompts one to think of numbers, which tends to fire us off into a numbers game that distracts from the fluidity and flex of the idea. The contrasting approach to local is global. Remember the early eco slogan, "think globally, act locally"? That notion of locality is what we're aiming at. (When we get to oriented change, we'll see the other half in action, too.) --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

sep. de 2020

time.minutes.short time.seconds.short

Human, 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 procedural and mechanical emphases. A common form of the problem is to implement a system using simple logic and uni-directional causality, abstracting away the complexity and sophistication of how humans actually perform at their best. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

sep. de 2020

time.minutes.short time.seconds.short

To 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 a thing is waste. After all, why did we build it all if we're just going to turn around and change it to get to the City on the Hill? Why not just build it that way to begin with? This idea, that change is bad, that we should avoid having to change our systems, absolutely permeates the culture of software development, to the point where it is less an intellectual construct and more of a gut-level instinct. The RAT seems to actually *fear* change. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

sep. de 2020

time.minutes.short time.seconds.short

Change-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 read countless books about software design. I've had my favorites, and I'm sure you've had yours. Some of my favorites really don't stand the test of time, of course, they were just "right time right place" for me to absorb their ideas and put them into play. The majority of these books present examples and arguments from a standing start, a blank page, a green field. The author presents a "design problem", more or less rigorously, then shows one or more solutions to 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

sep. de 2020

time.minutes.short time.seconds.short

A 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 often aimed at me because I have had some success. I should say: being a successful change-enabler doesn't mean batting 1.000 anymore than being a successful batter does. .300 is damned good. It means one fails 70% of the time. Making sticky change looks a lot easier than it is, *especially* when the looker ignores humanness. Here's the thing: whatever brilliant new arrangement I have in mind, I am very rarely the one who's going to have to make it. (Sometimes, I'm *one* of the ones who'll have to make it, but that's not quite the same thing.) Who makes it? The humans do. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

sep. de 2020

time.minutes.short time.seconds.short

When 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 the CHT model as being a daisy-chain of RATs. Each step is a “mini-RAT”, on a scale of a couple of team-days each. But that’s only if we ignore implementation differences. And they’re too big to ignore. In fact, I’ll venture out on a limb a little: ignoring the tremendous difference between RAT implementations & CHT implementations amounts to the second-biggest reason most “agile transformations” fail to bring actual improvements. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

sep. de 2020

time.minutes.short time.seconds.short

Let'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 development as an off-line program-construction activity composed of these parts: defining, decomposing, estimating, implementing, assembling, and finishing. We'll get to the parts in a second, but the CHT model's lead-in statement is already markedly different. The CHT model sees software development as an interactive and on-line program-alteration activity. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

ago. de 2020

time.minutes.short time.seconds.short

A 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 environments, flows are page-to-page. In desktop apps, they're set up like wizards. It doesn't matter, the key is that we're stepping the user down a single path in the directed graph. They neither know nor care whether there are other nodes that don't concern them. I start by identifying my "cop-out". --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

ago. de 2020

time.minutes.short time.seconds.short

The 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 internal software quality and external software quality. The yabbit takes this form: "Yeah, but we can get it done faster if we settle for it working less well." See, here's the thing: that's generally true. We *can* deliver more quickly by settling for a lower level of value. The trick is to understand the yabbit as being about *external* software quality, not *internal* software quality. --- 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 interested in becoming more involved in the Change-Harvesting community, click here to learn how to join GeePaw's Camerata. --- Send in a voice message: https://anchor.fm/geepawhill/message

ago. de 2020

time.minutes.short time.seconds.short