Thread by @GeePawHill

i genuinely believe that nearly all the woe in software development, the whole socialtechnical enterprise, derives from the belief that we can sidestep increment & iteration, "a little better now" and "we'll change it again later".

this applies to the purest coding geekery, and it applies to the schmooshy marketing, and it applies to the structures and process. it applies everywhere we make changes, and in software, everywhere we make changes is everywhere.

when i make attacks on certainty, i'm saying that i think they've sidestepped i&i. when i push against "one best way", i'm pushing off from i&i. when i advocate always small, always better, always rework, you guessed it, that's just me giving i&i it's true value.

the hardest part of i&i to grasp is actually their interconnectedness. everybody gets increment at first blush. "we will split the journey into pieces, and each piece will be one increment closer to the destination".

the problem with that first blush approach is that travelling from NY to SF is so trivial a problem as to be incomparable with the problems we deal with in the software-for-money trade.

marketing is way harder than travelling. coding is way harder than travelling. managing? way harder. process changing? yep, way way harder.

you see, none of these problems *split* well, the way lines on a map split at towns. with a map, the splits add up. every day i get closer. each increment adds to progress, and no increment ever goes truly backwards or even very sideways.

but in our problems, the splits are far more challenging to make. it has to do with a variety of factors. three of these stand out large, tho, so i'll enumerate.

first, the destination moves around. SF does in fact move very slowly over time, but on the scales at which travel takes place, it's negligible. in software-for-money, destinations move fast and unpredictably.

second, even if our destination holds relatively still, the territory between us right now and that destination is largely unexplored, and thus more or less impossible to draw in simple increments.

third, because there are people everywhere in our problem, we must constantly account in our splitting for the whole staggering complexity of what people can do when, and that is far beyond the dictates of simple reasoning.

so what we're saying is that the increment part can't stand by itself. plotting a route and progressing additively along it every day just isn't enough to get us there.

it's very important that we grasp that this is not about desire or will. yes, of course we wish it were so. yes, of course we are willing to throw considerable effort at making it so.

but we can't make it so. our desire and our will have to drop in the face of the reality.

enter the iteration. the second i of i&i is the acceptance of the continuous reworking of increments we have already taken.

iteration here is the repetition of change: we are changing things we already changed. we are assuming, further, that we will change them *again*, the third, the fourth, as many times as we need to to produce interactive splitting of our journey.

it's like viewing each increment as tentative, a probe, an exploration, an experiment. we engage in those increments because we believe they'll result in forward motion, but we accept that our belief and the world are two very different things.

this is not a simple relationship, between the two i's, and we want to be careful not to underestimate its impact.

because i am iterating, i can make my increments small and fast. because i am iterating, i must make those increments suitable for revisiting.

because i am incrementing and iterating both, i must resist sitting still while i try to figure out exactly how it's gonna go.

because all of our workers are i&i'ing they need training and experience to give them mastery of the techniques, and they must surely have healthy (iterated) doses of purpose and autonomy.

fear is the killer, and we must provide teams doing i&i with the safety to be wrong, and the techniques needed to make "being wrong" relatively cheap to us.

and because the work is incremental but with uncertain results, we must expect a high need for rhythm, the frequent building and releasing of compressed tension.

this all adds up to a *lot*. as we might expect with a sociotechnical enterprise, we will be constantly mixing technique, structure, and human interaction.

people want so much for there to be an easier way. even some folks within our own tradition market their technique as easier, and some no doubt believe that.

i want an easier way, too. but there isn't one.

if we are to succeed at software for money, we've no better choice at this time than to master the ins & outs of increment and iteration.

"change it better now" and "change it better again later".

and here's your blog, to make it easier to yell at me: "I&I: What 'Increment And Iterate' Means" geepawhill.org/ii-what-increm…