The Thinking Knee & Agile Practice: Beyond Coding

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 there is to agile: means to outwit the thinking knee. i don’t believe that.

i’m using “fighting the thinking knee” as a lens to help us clarify & unify a bunch of behaviors that don’t seem related on the surface. and as a lens, it’s useful. but it’s partial. lots of parts of the agile practice have little to do with the thinking knee. still, as we push out from coding practice, i hope you’ll see that the idea of the non-linear thinking knee is still useful in our considerations. let’s go to it.

almost every “make it smaller” impulse you see has as part of its rationale based in cheating the thinking knee. making things smaller, after all, very often directly reduces the piece count. if we force all stories that get to be WIP to be two days or less of work, we’re very likely reducing the number of points a given story touches the existing code. that’s piece count.

why have five daily 12-minute standups instead of one weekly hour-long standup? one of the reasons, smaller scope, which is just another way to say fewer pieces.

not all of the tricks are this direct. consider pairing & mobbing. do these reduce the piece count? no. they really don’t. does that mean they’re not related at all to the thinking knee here we step into chunking. we said before that all chunkings aren’t created equal. some “work” better than others. what’s one way we can get *better* chunking?

well, “better chunking” certainly seems to be closely related to “shared & sharable chunking”, doesn’t it? pairs & mobs have among other effects that they help create chunking schemes that are consistently more nearly optimal.

we prate endlessly on smaller cycle times. shortening these actually relates to the thinking knee twice.

first, smaller cycles usually still means fewer pieces, the direct contact. anything i can turn around in a few minutes is likely to involve far fewer parts than what i can turn around in a few days. but shorter cycles connects in another way. do you know that WIP items are *also* pieces? someone in our team, often several of us, is looking at our board, and sees each WIP item as a piece that must be thought about.

shorter cycles means literally that WIP items live shorter lives. and that, in turn, means that there are fewer that need to be balanced in our minds at one time. so things that reduce WIP, either directly by having fewer lanes, or temporally by having shorter time in the lanes, connects right back to avoiding the thinking knee.

(aside: the technique of swarming, which gets little press but is super powerful, exists almost entirely for this purpose. swarming is when a team takes one story and distributes its pieces to the *entire* team rather than to a single individual, pair, or mob.)

one reason chunks work is because they open & close. they form mental boundaries around pieces & other chunks. we can be inside the boundary and deal one way, or outside the boundary and deal another way. getting work “done-done” is a way of closing a chunk. it takes the chunk and removes its guts from view. all of the tricks that work by shortening cycles do roughly this same thing.

CI is a form of this, and so is CD. oddly, so is the part of TDD that lets me push the code whenever my tests are green. these all work in part by allowing us to take a piece or pieces that are *in* our head and move them *out* of our head.

so, i think i’ve just about exhausted what i needed to say about non-linearity, the thinking knee, and agile practice, at least as a separate topic. (i’m sure it will come up in passing again, for no other reason than because once you start looking at the thinking knee and our ways to work around it, you can’t *stop* looking at it.)

the conclusion i’d wish you to draw: the non-linear thinking knee presents a huge challenge in s/w development, one we’ve spent decades tackling in a variety of ways. agile practice, coding & non-coding, is the latest wave of these efforts.

the behavior i’d wish you to consider: explicitly considering piece-count, the knee, and all the creative ways there are to keep your chunks — scope — as modest & narrow as you can.

the thinking-knee can’t be eliminated. it is a fact of the biological limits of humans. but here and there, now and then, we can find ways to hold it at bay. agile practice represents among other things our best latest efforts to identify & take advantage of these ways.

The Thinking Knee In Coding Practice

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 speaking of is expressly that it makes it hard for *humans* to *think* about the code. “structured programming,” the movement surrounding this paper, is almost entirely an effort to start minimizing and organizing the pieces of code we have to think about.

tho some of its tenets have been softened over the years, the gist of structured programming is nearly invisible to us: it is the air we breathe. most of us take single-entry (not so much single-exit) named functions taking parameters & returning values entirely for granted.

so people who theorize about the human act of coding have been wrestling with the thinking knee in a variety of ways for a long time. the agilists have forwarded this movement, but we didn’t start it and we’re not done with it yet.

not all such efforts have been successful by the way, and one illustration of this might actually help us here: simonyi’s now much-derided hungarian notation. (for those who didn’t suffer through this, hungarian notation is the practice of pre-pending type info to variable names, so iCount is an integer, afPoints an array of floats, or such-like.) the impulse — help geeks think about their code — was good. the belief that providing more info about a variable whose declaration was very far away, not so good.

from a thinking knee perspective, hungarian notation says/does nothing about the piece count, it just attaches extra info to each piece. the result may have been slightly net-positive, tho that’s debatable. in the end, hungarian was discarded because it wasn’t free and it didn’t attack the *main* problem: piece count itself.

so how *do* we attack the piece count to keep from loading ourselves past the thinking knee? (speaking strictly about coding for today, we’ll zoom back out later.)

in miller’s even more famous paper, “The Magical Number Seven Plus Or Minus Two”  he posits that the human thinking knee happens when we get up between 5 and 9 pieces.

(aside #1: you really ought to *read* this paper, as it is not only fascinating in its conclusions, but is both charming & rather funny. it puts to rest thoroughly the idea that science writing can’t be great writing. aside #2: most modern psychologists would tell you that miller was wrong: the 60 years since have produced hundreds of experiments suggesting he over-estimated, and the real value is between 4 and 7 pieces.)

but if the thinking knee happens around 7 pieces, how do human thinkers do *anything*? how do programmers write programs containing literally hundreds of thousands of pieces?

the trick is called “chunking”. there are a lot of subtleties and sub-tricks involved, but the colloquial version looks like this: “put pieces in boxes. when you’re in the box, only think about it’s contained pieces. when you’re out, treat the whole box as one piece. chunking works. in some circumstances, it works very well, in others, less so. one way to see the last 40 years of coding theory is to see it as the working out of more & better ways to chunk things.

this is not an “agile” thing, not yet. single-entry structured functions *are* chunks. objects *are* chunks. the horizontal layers of layered architecture, the vertical stripes of microservices, the package/module/namespace stuff in most modern languages: all chunk facilitation. they are all about cheating the thinking knee by using chunks to get the piece count low enough that we can think effectively.

so agile coding practice isn’t an abrupt departure from the last decades of mainstream coding practice, but a continuation and extension of it. it is the latest of many waves whose focus is the thinking knee.

so much focus on *names*? strong names facilitate chunking. SRP and most of SOLID? clean boundaries between chunks.

what even *is* refactoring? “factor” is just another name for chunk. refactoring is rearranging chunks without changing function. there’s no possible reason for it *but* to facilitate chunking.

the microtests we prefer in TDD? the way we test interactively, test-code-test-code-test-code? directly about keeping piece counts small. (hard-TDD’ers, like myself, would add that TDD’s view of tests & testability as first-class participants in design is actually itself a way to encourage if not force good chunking.)

so. where are we?

some problems are non-linear. action cost goes up faster than piece count, sometimes so much faster it creates knees that we very much want to avoid. human thinking has such a knee. we use chunking to sidestep or mitigate its effects. coding practice has been about keeping programmers below that knee for at least 4 decades through facilitating that chunking and *agile* coding practice is in many ways an extension and retrenchment of this movement to ease the chunking process.

we’re almost there, and i’m relieved cuz i’m ready to be done with this topic for a while, but there’s one more piece, for next time: how does agile practice address the thinking knee in contexts around and beyond coding itself?