Simplicity is complex! [updated]

 posted Tuesday, December 11, 2007 at 6:48 pm MST

---

"In defence of complexity - part 1", a very nice post by Andrew Clifford over on ITtoolbox (It deserves a good read.) caused me to write a couple of comments there.

"we aspire to build simple IT solutions"
With respect, I don't think that's right. Or, better, it's right but not correct. So it's mis-leading.

I think the situation is more along the lines of "we aspire to have the complexity of our tasks accessed by means of processes and methods that are themselves simple".

Growing up in the age of a very young NASA I caught a wiff of their QA ... every step, every nut and bold, every component and solder joint and lead bend, everything was seen as an entity demanding due attention. (Anybody who's had to walk through FMECA knows how fast little things add up!)

So what you've written here rings my bell big-time: where's the sweet-spot between a crude functionality and an environment that's so rich that it results in helmet fire?

It's hard to make things seem easy ... and any system that makes things seem simple is bound to be complicated.

When I ponder the whole of your article I get an itchy/scratchy/burning feeling at the base of my scalp ... I think a lot of existential complexity is being masked by abstraction. "Fighter plane" is two words that signify one object which is, actually, 108 million components flying in formation.

Simplicity? Perhaps in the user's experience, but I can't think of where else it actually exists. So yes, your title makes the point nicely. Long live complexity, and may all be conscious and attend to it!

And then this:

"... how do we structure what we do so as to manage that complexity?"

I think that's the place to start. Taxonomy and ontology impinge directly (arise from?) our cognition ... our epistemology. (If the user doesn't relate to the system the way I anticipated, it's me who's wrong, however "correct" my design might be.)

"the IT implementation forces coupling between parts of the IT where there is no logical need to couple."

I'd like to think that this comprises a real opportunity for innovation; what we might be seeing is some sort of tipping point ... quantitative change becomes qualitative change. (I think that might be Hegel.)

If practice imposes kludges, then good on us for finding work-arounds ... that's just adaptive behaviour. But a rigorous consideration of that situation might lead to a new appreciation of the flow as a whole. What made the status quo clunky? Most time what is now klunky legacy was, in its time, state of the art. Has our appreciation become more refined? or have our work flows evolved so they now impose new demands?

I again come back to Heidgegger on techne ... more of the same may be a sufficient fix for the moment (I'd like to think IT-types get to sleep well rather than fretfully,) but at some point we have to read the tea leaves and adapt. (Just now I was thinking about "productive friction" and stood that on it's head, coming up with "Inertia is just momentum on the wrong vector" ... what do you think? *grin*)

cheers

p.s. when I reached a quantum tipping-point with concept mapping I reconceptualized what I was trying to do; reading at once texts by both John Willinsky (on OpenAccess) and Jurgen Habermas (on "discourse ethics") I came up with what I call a "discourse-based document portal". No investors yet, but after 5 years the fundamental innovation remains vital and vigorous, if only in my own mind.

p.s. in that exchange I also pointed to Joel Spolsky's "Don't Let Architecture Astronauts Scare You"

---

Another installment:/p>

A lot to chew on ... and at least one major disagreement that might just be a question of wording. To start:

"All innovation must be constrained by rules of structure and ownership."

What interests here is that having that true as a matter of principle doesn't mean that the principle is actualized and operationalized. It should be a matter of, well, work-flow, no? If I change some core code and buddy freaks out when he sits down Monday morning because he's faced by a radically different GUI, then I've obviously stepped out of my corral. That wouldn't make for happy Christmas parties. And yet (pretending that I'm a programmer and not just a coder) if I learn of a technique that will make his GUI at once less cluttered and more responsive, then there have to be channels that respond to that, as a positive stress.

But let me get to where I tripped:

"It doesn't matter whether the good idea involves just working around a kludge, a breakthrough innovation, or a much-need re-evaluation of existing work."

But "matter" is exactly what it would do, because those three situations have different histories and different scopes. The precise nature of the stress/tension is what dictates the character of the response, no? If something breaks and buddy's GUI is pretty as store-bought candy and posting false data then that's materially different from having to deal with the fact that the legacy system that's been groaning along for the past five years must must must be addressed at some point.

A specific: when you write "Even a simple change like implementing two logically separate databases on ..." I'm not sure that this necessarily ramifies upwards. If the product is identical after the improvement, why would the business unit care? Perhaps they'd be requested to perform backups, or to get ready for a possible outage, but ...
Or, similar but in another direction, "changing the database configuration, or a faster algorithm, or some such. Go ahead and do it, it's your job." ... really? Okay, I can see that. So long as it doesn't impact operations.

I wonder ... are we here treating IT as a black-box? data goes in and information comes out and the minds at work don't factor into others' thinking or planning? I can't help thinking of a football team ... the quarterback needs to know where his receiver is expected to be open, even though it's up to the receiver to get there ... the play is a unitary whole; all players shallRPTshall be on the same page, so while they individually responsible for their own execution it's only the details of their operations that are transparent / invisible to the other players.

Perhaps it comes down to what you say at the end: "[it's] about restricting the power of IT to accidentally impact business" ... totally. And perhaps the real hinge in there is communications: arbitrary "improvements" can seem like no more than mischief, change for the sake of change. I mean ... we talk about "user experience" on the web, but maybe something like pride of ownership can bridge the gaps.

I for one am painfully exasperated by how much tech is fielded for the sake of fielding yet more tech ... the name of the game is, after all, to fight off the alligators and get the swamp drained!

p.s. I was reading AJ Ayers' "Language Truth and Logic" in boot camp. The drill sargeant never let me live that down huh huh. But really, you should add Heidegger's "Essays on Technology" to your list. I'd say it isn't a bit academic.

---