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