yesterday's irritated blurt was a matter of feels, not an attempt to offer insight or ideas. i got some queries about it, so let me wipe that slate and be a little less irritated. for now, anyway. :)
in geekery -- in all tool use beyond a certain point, but my focus here is on the modern software development synthesis -- we confront problems that have a size that is "too big to eat all at once".
this is hardly news. human beings have been solving problems that were too big solve in one go since well before recorded history. yuval harari argues convincingly that this is because of our unique ability to form shared imaginary worlds. (francisco varela also argued thus.)
one solves big problems by decomposition: we split the big problem into several smaller problems, possibly recursively for a few levels, until all the problems inside the big problem seem soluble. then we solve them.
none of this is remarkable, and my story begins exactly there: the unremarkability of this idea, the unstudiedness of it, can create for us significant mistakes in our action.
an idea like "decompose problems until we have problems that are small enough to eat at one go", we'll shorthand it to decomposition, comes to us by both nature and training.
and like nearly all ideas, it comes with lots of nearby concepts, relationships, attitudes, and so on. ideas always come dirty like this. (that statement is in fact the beginning of my critique of positivist/neo-platonist/essentialist worldviews.)
a metaphor: decomposition is purest gold. we mine the world of ideas looking for that kind of gold. but we never find it, really. what we find is the ore out of which we might be able to refine gold.
when we let the unrefined ore substitute for real gold -- taking it in and using it as if it were the pure metal -- we can easily create big problems for ourselves.
what are these impurities? they are the less valuable "co-presenting" ideas that surround the good stuff.
what are these impurities? they are the less valuable "co-presenting" ideas that surround the good stuff.
i could go on at length, and normally do, but let's see if i can focus on the specific combination of ideas that co-present with decomposition that lead so many folks astray.
(let me interject: the part that gets rage-tweets isn't that we make mistakes. mistakes are necessary and good. it's that we make the same mistakes over and over because we don't adequately challenge the ideas that lead to them.)
so, co-presenting with the idea of decomposition -- dirtying its application in the world -- are a host of ideas that are far less pure. the specific behavior they lead to that troubles me the most in the world of geekery is the "endpointing long-term production".
endpointing is choosing a far-off target and restricting action (& words & analysis) to what we judge that will be relevant when (if) we get there.
that's pretty abstract, let's bounce one step closer.
that's pretty abstract, let's bounce one step closer.
"this feature will take a quarter. we will decompose it in to these stories, each of which will take about two weeks. database changes, service api's, data collection, event bus, business rules, and UI, and hardening, each of which will take two weeks."
to some of you this will seem a straw man: nobody works that way, you'll suggest. a) you are mistaken, plenty of shops still work that way. b) it is entirely transmutable into a 13-day story instead of a 13-week one, and still has all the same problems.
co-presenting ideas, then.
1) decomposition is best done in abstract mind-space because humans can manipulate ideas there for free, and there are no scope limitations there.
2) all decompositions that work in abstract mind-space work in real life, because mind-space is like real life to an abitrary epsilon at all scales.
3) problem-definitions are stable enough that they will still decompose the same before we solve them as they are after, regardless of how long it takes.
4) the only thing that matters is the final recomposition at the endpoint, all other factors are irrelevant.
notice that the value of those co-presenting ideas is highly sensitive to the duration from here to the endpoint. it's entirely non-linear. at 13 weeks, not one of them is true. at 13 minutes, all of them are. what about 13 days?
at 13 days, the odds are still slanted very heavily against you. in many 13-day durations, none of them are true. in some, a couple of them are. very rarely do all four co-presenting ideas hold water.
and yet -- in spite of very serious analysis, and considerable data -- we routinely structure our actions and our analysis around the idea that it is "efficient" to hold those co-presenting ideas to be true at 13 days.
so. the rage-tweet was here:
i hope it makes more sense now. the situation that triggered it was not a single horizontal decomposition -- into sub-problems none of whose solutions were shippable until all of them were -- but the policy of using that kind of decomposition and justifying it as efficient.
for the threading impaired, here's "Decomposition Rage Tweet Explained" geepawhill.org/decomposition-…
