Hey Folks! It’s a new site. If you see bad links or odd behavior, please contact me right away. Thanks! – GeePaw
 Home  Home  hom  Meet with GeePaw  Meet with GeePaw  mee  Work with GeePaw  Work with GeePaw  wor  Who's GeePaw  Who's GeePaw  who  Blog  Blog  blo  Contact  Contact  con

I&I: What Increment & Iterate Means

 7. May 2018

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.

  1. 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.
  2. 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.
  3. 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.

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