Underplayed: The Correlation Premise In Depth

TDD, Geekery, Modern-Synthesis / / 6 minutes of reading
This entry is part [part not set] of 9 in the series Underplayed Premises

Five underplayed premises of TDD includes the correlation premise. The correlation premise says "internal quality and productivity are directly correlated". Confusions and misunderstandings around this premise abound furiously, so it’s worth taking some time and working it out in detail. When we say internal quality (IQ) and productivity are directly correlated, we mean that they go up together and they, sadly, go down together. Their trend lines are inextricably linked. The first thing we have to do to parse this […]

Underplayed: The Correlation Premise In Depth See Full Post

Underplayed: The Money Premise In Depth

TDD, Geekery, Modern-Synthesis / / 6 minutes of reading
This entry is part [part not set] of 9 in the series Underplayed Premises

We talked about five underplayed tdd premises before, here’s a video & transcript. over the next couple of weeks, I’d like to take a little time and go over each of them in more depth. Today, let’s start with the money premise. The money premise says: "we’re in this for the money." TDD is fundamentally about making money. In software, we make make money by Shipping More Value Faster (SMVF). I’ve been doing, teaching, writing, arguing, and coaching TDD for

Underplayed: The Money Premise In Depth See Full Post

The Thinking Knee & Agile Practice: Beyond Coding

TDD, Geekery, Modern-Synthesis / / 4 minutes of reading
This entry is part [part not set] of 2 in the series The Thinking Knee

We talked at great length about how agile coding practice can be seen as combining several attempts at attacking the thinking knee, but what about agile non-coding practices. As I push towards the topic, which is it what got me started on this set of muses, I want to offer a bit of caution before we start. I’ve used the thinking-knee idea to elucidate a bunch of seemingly unconnected corners of the practice. It might seem I believe that’s all

The Thinking Knee & Agile Practice: Beyond Coding See Full Post

The Thinking Knee In Coding Practice

TDD, Geekery, Modern-Synthesis / / 5 minutes of reading
This entry is part [part not set] of 2 in the series The Thinking Knee

We’ve spent some time on the thinking-knee, but i’m not quite done with it yet. Let’s narrow our focus for a minute, to matters strictly around code & coding. Programmers have been thinking directly & indirectly about ways to evade or at least mitigate the effect of the non-linear thinking knee more or less forever. Dijkstra’s famout short paper, "Go To Statement Considered Harmful", from ’68, is an early example. He doesn’t invoke the knee explicitly, but the harm he’s

The Thinking Knee In Coding Practice See Full Post

Non-Linearity & The Thinking Knee: More On Fundamentals Of Agility

TDD, Geekery, Modern-Synthesis / / 5 minutes of reading
This entry is part [part not set] of 2 in the series Non-Linearity

So we talked about non-linearity in this previous post, wrapping it into the context of explaining why we prefer continuous integration (CI). But non-linearity isn’t just a good rationale for CI, it’s actually a driving factor for several of the practices of agility. It’s worth it to take a little more time to look hard. We’ve said that some problems are linear and some non-linear. Non-linear problems don’t just get bigger when you add more pieces, they get "bigger-er". Why?

Non-Linearity & The Thinking Knee: More On Fundamentals Of Agility See Full Post

Some Problem-Patterns I Look For

TDD, Geekery, Modern-Synthesis / / 3 minutes of reading

I remarked en passant the other day that I never see places where the biggest problem was sprints. Someone asked me what I do often see as the biggest problem when I walk in to a new shop? This gave me a lot of thinks. There are certainly things one sees over and over again. But most of these are small. On the other hand, there are a small number of, idunno, problem patterns, that seem much more ever-present. It’s

Some Problem-Patterns I Look For See Full Post

Linearity & Non-Linearity & CI

TDD, Geekery, Modern-Synthesis / / 5 minutes of reading
This entry is part [part not set] of 2 in the series Non-Linearity

When we talk about software methods, very early on we come to a place where we simply have to develop a comfortable grasp of non-linear effects. So many conversations founder here, where the relationship between two values becomes something other than a more or less straight line on a piece of graph paper. We spend a lot of time talking about the cluster of concepts we normally shorthand as "complexity". That’s a good enterprise, I think, but I also think

Linearity & Non-Linearity & CI See Full Post

Sprints vs Pure Pull: GeePaw Takes A Stand

Geekery, Modern-Synthesis / / 4 minutes of reading

So, there’s a lot going around just now about iterations vs pure pull. I feel like I want to weigh in on this one. I should say at the outset, as a coach the presence or absence of iteration/sprint is not a major outrage for me one way or the other. I routinely encounter sprint-based methods. Somewhat less frequently do I see attempts at pull, tho at industrial logic we’ve used pure pull for our product development for many years.

Sprints vs Pure Pull: GeePaw Takes A Stand See Full Post

Not Trying & The Fabric Of Coaching

Geekery, Modern-Synthesis / / 4 minutes of reading

We’ve got this long (and still probably partial) list of reasons why people don’t try new things. In recent weeks, i’ve gone pretty far afield around coaching. I picked out four or five threads separately and ran with each, separately. If it seemed a little incoherent to you, well, you know, join the club. Analyzing individual threads isn’t necessarily the best way to analyze a fabric. I confess to feeling a little bewildered as I wrote it. I get you

Not Trying & The Fabric Of Coaching See Full Post

Why They Don’t: Reasons People Won’t Try Something New

Modern-Synthesis, Geekery, Coaching / / 4 minutes of reading

Yesterday I asked my timeline how they would answer "Why don’t people do what my software development method says they should do?" I am not remotely surprised that the answers I got were almost exclusively thoughtful and sensitive. The people I hang with are just like that. I want to review the answers, but i’m going to do it by re-framing them all in terms of "trying a new thing". After all, as coaches, we are kinda in that business.

Why They Don’t: Reasons People Won’t Try Something New See Full Post

Scroll to Top