"Silo" by any other name would be as ...

Anchor for this item  posted Saturday, December 15, 2007 at 5:22 pm MST

*email blurted while I was waiting for spag and meatloaf to heat*

Looking at the Dec2002 prototype stuff I just posted for you ... that always brings me back. Do folk realize the social engineering that went into creating the Global Indymedia Network? That came about in 1999 ... but it's "radical" or "pinko" or "leftie" or something, so it doesn't count. *shrug*
Anyhow, that's not what I'm writing about ... but I did do a bit of a flash-back just now.

I think the "About" I wrote at Many2Many sets it out pretty well ... but there's something happening at a societal / cognitive level that makes it read like fluff.

"We shouldn't silo information" ... I'm sure you'll agree that most any information worker you or I would run that past would have an immediate sense of what we were talking about. Really? Really not. A conceptual understanding is not the same as an existential or experiential appreciation and, to the point: conceptual understanding doesn't operate like experiential appreciation. Kinda like ham&eggs with the chicken and the pig ... they share a relationship, but one is operating at a different level.

Ignoring blogosphere for the moment (How many hundreds of thousands of good posts have received no comments, pretending that they've ever been read? And how many posts with comments have had the thread die from something like an attentional version of anorexia? And all the while MySpace and FB are bolemic!) I focus on forums ... how many forums? how many discussion sites, like those in newspapers? how many mail lists? The sheer degree of "silo" has to be taken into account, else the concept fails to operate as an existential ... it has no weight so long as, disconnected, it remains an abstraction.

Case in point, dealing specifically with "concept mapping": feast your eyes on this slab of maps stored in Mindomo.com, picked more or less at random ... page 8 of, gawd, how many? Those are 9 of 2499 maps on file. How many individuals' work? How many hours? *shudder*

But with that I was kinda trying to set you up for a joke ... that site? Mindomo? It's relatively trivial in terms of size and maturity compared to the number of documents hosted by the Compendium community. Talk about siloing? That app (very mature and very sophisticated) uses the internet, but is essentially invisible ... along with its members and their work.

There is 1 country called Iraq. There is 1 war in that country. There is 1 discussion about that war. However shattered and fragmented and inchoate and splintered ... there is 1 reality. That's why the founders were satisfied with merely "the pursuit of happines"; the framers of the constitution understood reality existentially, experientially, and so their thinking was in-formed by more than conceptual constructs and elaborate abstractions.

Discourse ... the term is kissing cousins with enlightenment. (Our civil freedoms arose from the movement called "rationlism" ... we called that time "the age of enghtenment", though it had nothing to do with guru-beads and incence ... it gave rise to the "emancipation project".) When we become disconnected we don't appreciate the existentiality of discourse ... or enlightnment ... or emancipation ... or democracy. Then we lose our civility. Then we are stripped of our rights. Not in the abstract: concretely. And at that point we have nobody to complain to, nobody to share with ... and we long for emancipation and discourse.

HeyHo!

15DEC07 1654MST

A slab of bookmarks from this week:

0 comments   |  

Add to Technorati Favorites! <>



Simplicity is complex! [updated]

Anchor for this item  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.

2 comments   |  

Add to Technorati Favorites! <>



I came across Joseph Scott's "EditInPlace, New Version, New Home" and checked out the new site ... which left me totally in the dark, it's new and spartan to the point of being cryptic.
But have no fear! A set of back-links to earlier blog posts (18APR07 and 7JUNE07) and a well implemented tag system makes everything clear.
Also, Drew McLellan at 24Ways covers the topic nicely with his "Edit in Place With AJAX".

J. Scott's ''example'' page shows what it's all about ... shows how elegant the method is, too.
Now, let's make it accept HTML so we can really edit!

0 comments   |  

Add to Technorati Favorites! <>





Blog Flux Directory
bentrem

Performancing Performancing