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

Assumption Boxing is Harmful

 15. July 2017

I’m thinking of maybe a new geepaw coinage: something like “assumption-boxing”.

This is when we frame a problem with an assumption that narrowly limits (boxes) the range of solutions. A real-world example we’re all familiar with: “Optimize meeting structure to exchange status reports on individual’s sub-projects”. Do you see that “meeting structure” is a built-in assumption in the problem, & that it greatly boxes in the kinds of solutions we can have?

Long before most current geeks had seen a computer, Bentley describes a problem of moving architecture documents across a large urban area. The documents change a lot, and we need to be able to move them around to the various sites quite quickly. Moving them by car’s too slow. He lets us stew on our various high-tech solutions for a while, then lays out an idea that virtually no one ever suggests.

Microfilm and homing pigeons.

What he’s showing us is how in this case the assumptions we bring to the problem about possible solutions keep us from seeing a great one. This is what I mean when I say “assumption-boxing”. And it’s a problem in our trade not just for geeks but for those who operate within them.

Another common case: lockstepping. “How can we march these teams in lockstep so our large app is stable and predictable?” Again, the box or trap is created by the assumption: that some kind of lockstepping is the best answer. Most shops most of the time make a change by replacing solution A with solution B in situ. That means dependents on A must break. There are a lot of techniques that allow us to support A and B at the same time. but as a trade, we don’t know them or use them.

The answer is to develop code change-mindedly from the start. Get my teams to learn and use the techniques that allow staggered stepping. But since that’s not a lockstepping approach, we’ve drawn a box that excludes the right answer.

This is why we start thinking about a problem by focusing so heavily on what the problem is, not the solution. This is why the most important thing to understand about the work right in front of you is what value is being served. And this is why it’s so important, at the micro-level, to spend time looking away from the wall, doing something else.