I was reading Stephen Smoliar’s latest post on The Google Paradigm and its Discontents, and something he said struck me harder than it ever did before, even if he’s said it a million times. Now most regular readers know Stephen by now, he’s one of the most prolific commenters here. I agree with Stephen about many things; I disagree with Stephen about many things; and then there’s a large group of things I don’t even claim to understand as yet, and that doesn’t stop me reading what he writes.
I quote from that post:
As I suggested in the opensourcing discussion, we cannot talk about processes in any productive way unless we are as “epistemologically comfortable†with verbs and verb phrases as we are with nouns and noun phrases.
Something about what he said there made me think about the glazed look people used to give me when I first spoke about any aspect of software as a service. To many people, software is a noun and inanimate as well; to many people, service remains a “doing” word and closer to a verb despite being a noun. And this separation of service from software seems to create a whole series of problems in people’s minds.
The three biggest problems it seems to create are in the following areas:
Creativity: People seem to believe that software can be “clever” while service can’t; as a result, they seem to think that software is patentable, leading to all kinds of blind alleys. Which is why we now see terms like software-and-a-service, suggesting that there has to be a difference, and (at least in my mind) basing that difference on intellectual property lines.
Substitutability: For many years it has astounded me just how often oe particular class of projects fail, those based on replacing human labour with software. It doesn’t seem to matter just how mind-numbing the activity being displaced is, somehow the substitution never happens. This behaviour is at least part of the reason why many aspects of process re-engineering did not work, since processes were tied to people and doing, while the re-engineered components were tied to software. It didn’t matter what we did with the software, the people stayed on. Sometimes even grew in numbers. A variant of this happened in the offshore world. How else could you explain the focus on offshoring standardised repeatable cookie cutter tasks rather than those requiring human brainpower? Surely tasks that were standardised, repeatable and cookie-cutter would be excellent candidates for automation rather than offshoring? But what do I know?
Service innovation (which I guess is an amalgam of the two prior points). For some reason, whenever I’ve tried to drive a discussion similar to that on the opensourcing of process, I start hitting this noun-verb argument. In many people’s eyes, process as a concept seems very tied to people, in a way that software isn’t. Perhaps it’s a function of just how long the concepts have existed. This is the reason why we spend so much time carefully paving the cowpaths; in fact we’ve been doing it for so long that nowadays, when we find bits of road, we dig it up and pave them differently so that they continue to look like the cowpaths they never were.
Just musing.
I like that thought on creativity, those in the service delivery sector will be saying …. “There, I told you so….”
I’m sure the “Substitutability” is just a case of the “sharp intake of breath” as the folks justify the human tasks you’re trying to replace by making it sound more complex than it really is. Swathes of process maps to try and confuse ….in the same way people do with internal audit…… “give then mountains of documentation to wade through …. that should put ’em off the scent” ….setup to fail in the first pace.
Maybe that’s too cynical for a Sunday morning…
Interesting analysis – to see process as content and content as process is something we struggle with in education.
However, my favourite bit of new thinking comes from your inertia of the mind stuff – the “how long the concepts have existed” and the “reason why we spend so much time carefully paving the cowpaths” I am going to look more carefully at people digging up roads in education.
The thinking that draws the line between software and service should be getting shaky just about now, as people — you and I for example — crawl inside each other’s heads and talk through the comment box.
If I can stand inside your thinking and listen with my mind in this way, it’s no longer such a leap for me to stand inside my software and “think how my software works.” Is it?
The creativity of process and its tie to people comes notonly from the cynical, below the radar corporate mishandling of it (mentioned earlier), but also from the excellent, fluent use of process that shows that the most elegant process is adaptable to the circumstance of the situation and the people within it. How hard can it be to show someone that software does the same “fluent adaptation” for its users?
Have we just accepted that some folks have sorted the nouns and the verbs, that it’s not worth showing them how a gerund works because they didn’t get it in grammar school, so they couldn’t possibly get it now?
We fund those cowpaths that we pave. Have we suggested that they stop? My experience is that the most average person enjoys seeing the world in new ways. That we all have a need to make sense of it.
Would you help me understand where I may have misunderstood what I have read?
Andy, Artichoke, Liz, I believe we’re all on the same page, comfortable with gerunds as it were. What we need are some strong objections to what we’re saying, so that we can learn from them. I’m sure the strong objectors will turn up.soon.
The gerund is sort of a red herring in that it distracts from the role that verb phrases play in our ability to “think in time,” to borrow from the phrase Neustadt and May used for their book on presidential decision making. While noun phrases are basically about objects, attributes, and relationships (i.e. the stuff of databases), verb phrases have to contend with the subtleties of tense, mood, and voice. This is where the REAL epistemological chickens come home to roost!
relationships . . . hmmmm . . . between data sets and packets, between people and living things.
Both noun phrases and verb phrases are about relationships. Then, of course, you have the forms of “to be,” once lovingly referred to as the copulative verb. How much more relational than that can a single word get?
Liz, you make a good point; so let me apply it to refining my original assertion. The relationships addressed by noun phrases are relationships of STATE (which should be no surprise, since they serve to modify the noun of the noun phrase, which is an object). The relationships addressed by verb phrases are relationships of PROCESS, particularly those that are adverbial in nature.
Is the copulative relational; and, if so, is it a relation of state or process (or neither)? To use the word that got me into trouble, the copulative is “about” BEING. Whether being is a relationship of state or a relationship of process basically depends on which philosophers you prefer to read! My own preference is for the processual, which is basically a phenomenological stance that draws a lot from Heidegger. Regardless of what the copulative is “about,” however, it, too, is subject to all those subtleties of representation that I enumerated in my last comment (such as tense, mood, and voice).
The retarded hippie in me wants to say “heavy, man” which was how we used to say “I don’t understand”. What I do understand is relationship before conversation before transaction. Yes, cluetrain again….
JP, I suppose the appropriate hippie response would be: Hey, man, if you can’t dig BEING, then you just AREN’T THERE!
Meanwhile, skeptic that I am about the Cluetrain Manifesto, I have to admit that conversations are far more verb-based than transactions (and are, indeed, the primary vehicle for “managing” relationships)!
Oh, I don’t know if I’ll go this far with service vs. software divide.
Service is too broad a term (relatively speaking), and has been around for a long time.
Service, is closer to purpose than software is.
SAAS disabuses software from its traditional packaging and consumption mechanism.