perhaps we should go back to Steven Katz' "The Ethic of Expediency" in the context of this conversation. i will. but first, i need to find out what "dromology" is (and that's the price of my posting further on this :)
Alex, i LOVE the new design of your blog.
digitaldigs
· 6 months ago
Thanks Bonnie. I'd be interested in hearing your take via Katz. Certainly Katz's concern with expediency in terms of the Holocaust is relevant to Virilio, who is deeply concerned with fascism and technology. However, I would also point out that speed is not always expedient. Sometimes it is just wasteful. That is, maybe what interests me about speed is intensifications beyond the point of expediency.
blk
· 6 months ago
I think we agree re: speed. And I think that Katz is making a similar argument about speed, that is intensifies in ways that show us (upon reflection) that we are truly, as Burke would have it "rotten with perfection" (again w/ the nazis). Thus, it *is* wasteful, in more ways than one.
very interseting. thanks for engaging.
blk
Jim
· 6 months ago
It's funny that you say this:
"I can say in my own thinking it works this way. And perhaps you'll take issue with it. But in research, reading, and writing, I know in an instant, intuitively I suppose, when I am on to something. Then it might be hours or weeks or months of work to be able to really understand that moment, at least within the terms of discourse in which I work."
That's the exact kind of feeling I had when I began to ask this question about speed. But then again, I'm not sure I can draw a distinction between this "intuitive" feeling that I was onto something, and the various encouraging feedback I received along the way. Jeff Rice recommended Virilio. Others' nodded as I explained rough sketches of the idea. I wonder when the "aha!" moment really came.
Nonetheless, your post is dead on, I think. Deleuze is my next step if this project continues to grow (and I think it will).
Skydaemon
· 6 months ago
Speaking from the perspective of a programmer, I suspect you could find parallels of what you were looking for in the recent history of our field.
I don't think most people have any concept of the speed advances that took place in development, or what we did to achieve them. I think they know something happened, but I don't think they realize how massive the behind the scenes changes were.
The larger structural and methodological changes forced on us by speed were actually quite valuable. It's to the point where the development approaches we used 15 years ago are completely unthinkable in retrospect. I'm referring to the manner of creation that we pursued, not particular languages, tools or algorithms or anything like that. We basically reinvented everything in our industry except the tools (which have themselves been getting reinvented anyway, but that's not as a result of speed requirements).
In programming, essentially we trashed our dogma and everything we "knew to be right" and started looking at results due to our overwhelming need to achieve speed gains. Then we rebuilt not only what we were building, but also how, and we even scrapped our concept of how teams should operate and businesses should be organized. Our metrics changed, our scheduling approaches changed, the interpersonal communications and management styles changed. Even our interaction with customers changed. Best practices evolved to focus on things that would've had no purpose in the prior approach. We redefined what was important, including our definition of risks and undesirable outcomes.
Where we previously tried to achieve flexibility through exhaustive planning, structure, and research, we evolved to handle that through speed and flexible goals instead. You don't need pre-built flexibility if you can create whole new works or components rapidly enough should that come up. Speed itself becomes the solution to contingencies rather than pre-built structural tolerance. Where we used to focus on complete integrated and rigid all-or-nothing monolithic works, we evolved to build works which were built in individually meaningful pieces. Base structural core components, with flexible endpoints which together make up the beast. The nature of the creation of such is that if you build it in a certain way, the overall usages of the final product can be largely changed right up until the last pieces are made with minimal rework.
We also began to understand the implications of the concept of a lifecycle more practically than we had before. Specifically, large amounts of our planning and structure were created for scenarios which didn't actually ever occur because the product itself would die and be replaced before the long range needs came up. Programmers had long thought of their creations as permanent during design. If you think your creation will be used for 50 years, you build in a lot of structure for contingent flexibility that has no use if the real lifespan is more like 8 years. We redefined waste to include things which were theoretically valuable but in a practical sense, never got used.
I've often considered it interesting that departments like English do not teach the process of writing in structural ways. They grade the outcome, but don't care about how writing happens. They have no structural methodology for creating books the way developers do for creating applications. Note that development methodology is rarely visible in the finished delivered product, it's all behind the scenes stuff. I'm not referring to paragraph structure or anything visible like that, I mean this in regards to the actual behind-the-scenes writing and creative processes themselves.
I suspect the English discipline avoids analyzing or giving structure to the writing process because they think it will stifle creativity, but I don't think that's necessarily true at all. To begin with, even software developers have a variety of methodologies from which they pick and choose. They certainly aren't required to do things a certain way, they are just given a host of options (although using nothing is considered unprofessional). But on top of that, ask yourself what is the creative part of the work. Is it the manner in which you created it, or is it the ideas that you combined on the page. If it is the latter, then that is not necessarily affected by the process used to create the work. In other words, in the latter scenario, writing could have formal processes taught, even if not always used.
Then again, maybe it's just thinking of written works as necessarily sequential entities. The situation of programming suggests there is no reason for this to be the case. Why should you write one page after another, instead of building up ideas which could hold parts of the final work, then linking them together to stitch the work together sort of from the inside out. If the latter gets done, that is similar to how programs are built and suggestive of the benefits of similar approaches.
Perhaps I should ask why programming requires methodologies so strongly. At it's root, I think it boils down to the requirement to work in teams. You can't collaborate rapidly with professional strangers without systems for doing so. If the work is small and completable by a single person, how it gets done isnt such a big deal.
I wonder then, if writing could be evolved to a team production focus. Where members could possibly have different disciplines. Picture a structural process that allowed a historian, philosopher, 3 or 4 english specialists and a scientist to jointly write a single work efficiently and in parallel. Not every specialist needs to know how to perform all the tasks even, just fill in their parts of the structure. Now picture such a team cranking out a book on a monthly basis or working on 8 books in parallel.
Jim
· 6 months ago
Great stuff here Skydaemon. A couple of things:
1) English/Comp. teachers (at least at the University level) are teaching the methods and structures that you're speaking of. It's happening...it's probably taking a while to trickle down/out...but it's happening.
2) You mention this approach:
"I wonder then, if writing could be evolved to a team production focus. Where members could possibly have different disciplines. Picture a structural process that allowed a historian, philosopher, 3 or 4 english specialists and a scientist to jointly write a single work efficiently and in parallel. Not every specialist needs to know how to perform all the tasks even, just fill in their parts of the structure. Now picture such a team cranking out a book on a monthly basis or working on 8 books in parallel."
This is the exact approach I'm teaching in a course called Anthologics (taught it last year, and teaching it this Fall). The class will approach a question of public policy by reading how people from various disciplines address that question. Then we'll build our own interdisciplinary anthology about the topic. Students will learn to see the differences between these different disciplinary approaches, and they will learn how to enact some of them.
Skydaemon
· 6 months ago
Thanks Jim.
1) I am probably just ignorant of what is out there. I've only ever taken two 100 level english courses (a decade ago) so even if it was common within the department it could've easily escaped my notice. Although your description makes it sound relatively recent.
2) Your course sounds very interesting. There's a lot of public policy areas that could use some serious interdisciplinary analysis these days (read: many policies are in need of some heavy duty fixing).
I'm not sure if maybe the implications of what I was suggesting were completely obvious so I'll expand a bit.
The kind of joint team writing I was suggesting would very likely require new collaborative tools or systems. Especially if combined with the kinds of techniques from point 1. Point 1 could've involved both team organization theories (Xtreme or Agile programming for example) or type of programming (eg, functional, object-oriented). Let's take a simple case and look at team "object-oriented writing" or something.
Let's look at what object-oriented writing might involve to flesh out the nature of implications. It's more of a thought exercise than anything concrete. I'm not even suggesting object-oriented writing is a good choice, just trying to show the nature of what I was considering.
Object-oriented writing does not start in a word document. In fact, many of these techniques will not be possible to start with a linear format like a word doc. That is part of the key break in thinking. Picture a book, then visualize links from the concepts in the book to a distilled deeper architecture, you could possibly iteratively delve deeper. So now the book can be viewed as a constructed artifact built from pillars of concepts, ideas, objects, or actors. It is possible to discard the book in the beginning, and begin the process by building the underlying pillars and connections as a product in itself. It is also possible to reverse engineer an existing book into these underlying architectures, concept pillars, and interactions.
It starts with object diagrams denoting relationships of the objects involved and lists of how they can interact, something equivalent to UML (unified markup language). It also displays their interactions between each other. Later on this is storyboarded into use cases. Demonstrations of how one would use such a thing to achieve an expected usage. Finally, these get plastered together in an actual written form. If you don't like UML and object modelling, you could look to the data modelling and interaction done within relational database schemas which is similar although a slightly different focus (on data interrelations specifically rather than objects and possible interactions).
Anyway, reducing it like this possibly allows you to benefit from the insights of experts in scientific or business fields who could help you flesh out what they're working on so that their work could be easily ported into discussions by various disciplines. You the writer don't have to research the bleeding edge new technology, you just import it and work with it as identified by the expert.
Say something like that was made to be successful, ignoring the difficulty or why you'd want to for a moment. The implications would stretch in several directions.
First, the objects created would take on a life of their own. By that I mean, they would not be bound to a single book, the objects created could outlive both book and author. In fact, if all authors got in the habit of creating these objects in a common form, then you could begin your book by taking already created objects existing out there, and bring new combinations into your book and expand on them. You would no longer have to think about the basics of each object, or how to describe it, or research it's interactions with common things or other ideas, that would already be there. It could potentially chop trivial research or thinking down immensely. There is no reason these object attributes couldn't link back to original sources if needed as well. You could expand on it, you could read through other author's listed attributes and interactive functions for this object as a creative exercise to spark ideas against your new approach. It would also help to keep track of the entire body of work out there that involved this object and the work that had been done. If you wanted to know all interactions between two objects or concepts that had ever been written about in your discipline (or perhaps other disciplines as well) then it could be possible to search for works which used that combination of objects. Basically the act of searching gets distilled and "total knowledge" on topics becomes potentially identifiable.
There are further implications. Once it is possible to denote stories in object diagrams and storyboarding in this way, it becomes possible to transform the act of creative thinking or writing itself into a visual process. Imagine being able to write a book skeleton using only a mouse. Arranging objects and interactions on storyboards in a way which basically tells the outline of the story without writing words. As a side note, looking at this, it also becomes glaringly obvious from the perspective of a reviewer when key interactions between concepts have not been addressed.
Consider the possibility that the translation to words and sentences from that object storyboarding could be automated. Now note that the language the final writing occurs in could be configurable. The complexity level (or reading level) could also be adjustable.
So now you have a new thing, where your book can be read by any audience in any language or at any reading level at the touch of a button, without things getting lost in translation. A self-translating book capable of molding to the viewer's reading ability. Really, you've distilled the book to it's concept, object and idea connections in a way that is abstracted from language or words. And since you aren't writing syntax (sentences), or researching what is available or well known things (since all that or at least source links are contained in a single place in the object which you can import) more of your time is spent fleshing out the real ideas, which hopefully makes you more productive / faster.
I guess the root idea is to no longer think of a book as a one dimensional thing. And move from there to actually doing the real work on levels beneath the surface. Note that I never said any part of this was easy!
Skydaemon
· 6 months ago
Sorry to keep coming back, but the topic has my mind rolling ideas around.
Thinking about it even further, what we might call writing style (word choice, sentence construction, and so on) could be described as what a programmer might call a "filter".
The kind of book mentioned above suggests the possibility that writing style could be selected and applied by the reader rather than the writer as a filter. Imagine being able to read your local newspaper as if it had been written by karl marx.
Right now the writer must apply the style since it can't be changed on the fly by the reader, but there is conceptually no reason this has to be so in a digital medium.
Everybody has writing styles that they like and some that they don't. Would it not be useful (more fun to read at a minimum) to be able to choose the style of what you were reading.
digitaldigs
· 6 months ago
Thanks Skydaemon. You offer some real insight into the changing compositional practices of programming. The simple fact is that speed has never been part of the academic ethos, let alone the humanities or English Studies. To the contrary, we have looked upon speed as unethical and characterize the market forces that demand speed of other professions as anti-intellectual.
Personally I find these moralistic arguments are falling somewhere between "wanting" and "uninteresting." They are "wanting" if one sacrifices other ethical-moral commitments that might be met through speedy intervention. But more importantly (at least to me), they are uninteresting because what I want to consider here is how speed creates an intensification of cognitive processes that leads to something new. I can't say what that new thing might be, so I can't place a value judgment on it (even if I wanted to, which I don't).
I do wonder if digital scholarship might incite some of the compositional practices you describe in programming. Sometimes a change in media can really shake things up. On the flip side, we don't need to be increasing the production of scholarship. We already have a glut! What we do need is to change the dynamics of scholarship, whether that means digital or not, though obviously I think it means digital.
Meanwhile I think your proposition of faculty writing in parallel to be a radical one. Of course we produce essay collections somewhat in this way, but here you're talking about something much more collaborative. The tough thing would be to find a half-dozen scholars in the humanities who would be willing to subordinate their differences to a common goal. Of course this happens all the time in virtually every other walk of life, but humanities professors are wired that way.
I think that's one of the major obstacles we face in building digital, collaborative scholarly communities.
All Comments
Alex, i LOVE the new design of your blog.
very interseting. thanks for engaging.
blk
"I can say in my own thinking it works this way. And perhaps you'll take issue with it. But in research, reading, and writing, I know in an instant, intuitively I suppose, when I am on to something. Then it might be hours or weeks or months of work to be able to really understand that moment, at least within the terms of discourse in which I work."
That's the exact kind of feeling I had when I began to ask this question about speed. But then again, I'm not sure I can draw a distinction between this "intuitive" feeling that I was onto something, and the various encouraging feedback I received along the way. Jeff Rice recommended Virilio. Others' nodded as I explained rough sketches of the idea. I wonder when the "aha!" moment really came.
Nonetheless, your post is dead on, I think. Deleuze is my next step if this project continues to grow (and I think it will).
I don't think most people have any concept of the speed advances that took place in development, or what we did to achieve them. I think they know something happened, but I don't think they realize how massive the behind the scenes changes were.
The larger structural and methodological changes forced on us by speed were actually quite valuable. It's to the point where the development approaches we used 15 years ago are completely unthinkable in retrospect. I'm referring to the manner of creation that we pursued, not particular languages, tools or algorithms or anything like that. We basically reinvented everything in our industry except the tools (which have themselves been getting reinvented anyway, but that's not as a result of speed requirements).
In programming, essentially we trashed our dogma and everything we "knew to be right" and started looking at results due to our overwhelming need to achieve speed gains. Then we rebuilt not only what we were building, but also how, and we even scrapped our concept of how teams should operate and businesses should be organized. Our metrics changed, our scheduling approaches changed, the interpersonal communications and management styles changed. Even our interaction with customers changed. Best practices evolved to focus on things that would've had no purpose in the prior approach. We redefined what was important, including our definition of risks and undesirable outcomes.
Where we previously tried to achieve flexibility through exhaustive planning, structure, and research, we evolved to handle that through speed and flexible goals instead. You don't need pre-built flexibility if you can create whole new works or components rapidly enough should that come up. Speed itself becomes the solution to contingencies rather than pre-built structural tolerance. Where we used to focus on complete integrated and rigid all-or-nothing monolithic works, we evolved to build works which were built in individually meaningful pieces. Base structural core components, with flexible endpoints which together make up the beast. The nature of the creation of such is that if you build it in a certain way, the overall usages of the final product can be largely changed right up until the last pieces are made with minimal rework.
We also began to understand the implications of the concept of a lifecycle more practically than we had before. Specifically, large amounts of our planning and structure were created for scenarios which didn't actually ever occur because the product itself would die and be replaced before the long range needs came up. Programmers had long thought of their creations as permanent during design. If you think your creation will be used for 50 years, you build in a lot of structure for contingent flexibility that has no use if the real lifespan is more like 8 years. We redefined waste to include things which were theoretically valuable but in a practical sense, never got used.
I've often considered it interesting that departments like English do not teach the process of writing in structural ways. They grade the outcome, but don't care about how writing happens. They have no structural methodology for creating books the way developers do for creating applications. Note that development methodology is rarely visible in the finished delivered product, it's all behind the scenes stuff. I'm not referring to paragraph structure or anything visible like that, I mean this in regards to the actual behind-the-scenes writing and creative processes themselves.
I suspect the English discipline avoids analyzing or giving structure to the writing process because they think it will stifle creativity, but I don't think that's necessarily true at all. To begin with, even software developers have a variety of methodologies from which they pick and choose. They certainly aren't required to do things a certain way, they are just given a host of options (although using nothing is considered unprofessional). But on top of that, ask yourself what is the creative part of the work. Is it the manner in which you created it, or is it the ideas that you combined on the page. If it is the latter, then that is not necessarily affected by the process used to create the work. In other words, in the latter scenario, writing could have formal processes taught, even if not always used.
Then again, maybe it's just thinking of written works as necessarily sequential entities. The situation of programming suggests there is no reason for this to be the case. Why should you write one page after another, instead of building up ideas which could hold parts of the final work, then linking them together to stitch the work together sort of from the inside out. If the latter gets done, that is similar to how programs are built and suggestive of the benefits of similar approaches.
Perhaps I should ask why programming requires methodologies so strongly. At it's root, I think it boils down to the requirement to work in teams. You can't collaborate rapidly with professional strangers without systems for doing so. If the work is small and completable by a single person, how it gets done isnt such a big deal.
I wonder then, if writing could be evolved to a team production focus. Where members could possibly have different disciplines. Picture a structural process that allowed a historian, philosopher, 3 or 4 english specialists and a scientist to jointly write a single work efficiently and in parallel. Not every specialist needs to know how to perform all the tasks even, just fill in their parts of the structure. Now picture such a team cranking out a book on a monthly basis or working on 8 books in parallel.
1) English/Comp. teachers (at least at the University level) are teaching the methods and structures that you're speaking of. It's happening...it's probably taking a while to trickle down/out...but it's happening.
2) You mention this approach:
"I wonder then, if writing could be evolved to a team production focus. Where members could possibly have different disciplines. Picture a structural process that allowed a historian, philosopher, 3 or 4 english specialists and a scientist to jointly write a single work efficiently and in parallel. Not every specialist needs to know how to perform all the tasks even, just fill in their parts of the structure. Now picture such a team cranking out a book on a monthly basis or working on 8 books in parallel."
This is the exact approach I'm teaching in a course called Anthologics (taught it last year, and teaching it this Fall). The class will approach a question of public policy by reading how people from various disciplines address that question. Then we'll build our own interdisciplinary anthology about the topic. Students will learn to see the differences between these different disciplinary approaches, and they will learn how to enact some of them.
1) I am probably just ignorant of what is out there. I've only ever taken two 100 level english courses (a decade ago) so even if it was common within the department it could've easily escaped my notice. Although your description makes it sound relatively recent.
2) Your course sounds very interesting. There's a lot of public policy areas that could use some serious interdisciplinary analysis these days (read: many policies are in need of some heavy duty fixing).
I'm not sure if maybe the implications of what I was suggesting were completely obvious so I'll expand a bit.
The kind of joint team writing I was suggesting would very likely require new collaborative tools or systems. Especially if combined with the kinds of techniques from point 1. Point 1 could've involved both team organization theories (Xtreme or Agile programming for example) or type of programming (eg, functional, object-oriented). Let's take a simple case and look at team "object-oriented writing" or something.
Let's look at what object-oriented writing might involve to flesh out the nature of implications. It's more of a thought exercise than anything concrete. I'm not even suggesting object-oriented writing is a good choice, just trying to show the nature of what I was considering.
Object-oriented writing does not start in a word document. In fact, many of these techniques will not be possible to start with a linear format like a word doc. That is part of the key break in thinking. Picture a book, then visualize links from the concepts in the book to a distilled deeper architecture, you could possibly iteratively delve deeper. So now the book can be viewed as a constructed artifact built from pillars of concepts, ideas, objects, or actors. It is possible to discard the book in the beginning, and begin the process by building the underlying pillars and connections as a product in itself. It is also possible to reverse engineer an existing book into these underlying architectures, concept pillars, and interactions.
It starts with object diagrams denoting relationships of the objects involved and lists of how they can interact, something equivalent to UML (unified markup language). It also displays their interactions between each other. Later on this is storyboarded into use cases. Demonstrations of how one would use such a thing to achieve an expected usage. Finally, these get plastered together in an actual written form. If you don't like UML and object modelling, you could look to the data modelling and interaction done within relational database schemas which is similar although a slightly different focus (on data interrelations specifically rather than objects and possible interactions).
Anyway, reducing it like this possibly allows you to benefit from the insights of experts in scientific or business fields who could help you flesh out what they're working on so that their work could be easily ported into discussions by various disciplines. You the writer don't have to research the bleeding edge new technology, you just import it and work with it as identified by the expert.
Say something like that was made to be successful, ignoring the difficulty or why you'd want to for a moment. The implications would stretch in several directions.
First, the objects created would take on a life of their own. By that I mean, they would not be bound to a single book, the objects created could outlive both book and author. In fact, if all authors got in the habit of creating these objects in a common form, then you could begin your book by taking already created objects existing out there, and bring new combinations into your book and expand on them. You would no longer have to think about the basics of each object, or how to describe it, or research it's interactions with common things or other ideas, that would already be there. It could potentially chop trivial research or thinking down immensely. There is no reason these object attributes couldn't link back to original sources if needed as well. You could expand on it, you could read through other author's listed attributes and interactive functions for this object as a creative exercise to spark ideas against your new approach. It would also help to keep track of the entire body of work out there that involved this object and the work that had been done. If you wanted to know all interactions between two objects or concepts that had ever been written about in your discipline (or perhaps other disciplines as well) then it could be possible to search for works which used that combination of objects. Basically the act of searching gets distilled and "total knowledge" on topics becomes potentially identifiable.
There are further implications. Once it is possible to denote stories in object diagrams and storyboarding in this way, it becomes possible to transform the act of creative thinking or writing itself into a visual process. Imagine being able to write a book skeleton using only a mouse. Arranging objects and interactions on storyboards in a way which basically tells the outline of the story without writing words. As a side note, looking at this, it also becomes glaringly obvious from the perspective of a reviewer when key interactions between concepts have not been addressed.
Consider the possibility that the translation to words and sentences from that object storyboarding could be automated. Now note that the language the final writing occurs in could be configurable. The complexity level (or reading level) could also be adjustable.
So now you have a new thing, where your book can be read by any audience in any language or at any reading level at the touch of a button, without things getting lost in translation. A self-translating book capable of molding to the viewer's reading ability. Really, you've distilled the book to it's concept, object and idea connections in a way that is abstracted from language or words. And since you aren't writing syntax (sentences), or researching what is available or well known things (since all that or at least source links are contained in a single place in the object which you can import) more of your time is spent fleshing out the real ideas, which hopefully makes you more productive / faster.
I guess the root idea is to no longer think of a book as a one dimensional thing. And move from there to actually doing the real work on levels beneath the surface. Note that I never said any part of this was easy!
Thinking about it even further, what we might call writing style (word choice, sentence construction, and so on) could be described as what a programmer might call a "filter".
The kind of book mentioned above suggests the possibility that writing style could be selected and applied by the reader rather than the writer as a filter. Imagine being able to read your local newspaper as if it had been written by karl marx.
Right now the writer must apply the style since it can't be changed on the fly by the reader, but there is conceptually no reason this has to be so in a digital medium.
Everybody has writing styles that they like and some that they don't. Would it not be useful (more fun to read at a minimum) to be able to choose the style of what you were reading.
Personally I find these moralistic arguments are falling somewhere between "wanting" and "uninteresting." They are "wanting" if one sacrifices other ethical-moral commitments that might be met through speedy intervention. But more importantly (at least to me), they are uninteresting because what I want to consider here is how speed creates an intensification of cognitive processes that leads to something new. I can't say what that new thing might be, so I can't place a value judgment on it (even if I wanted to, which I don't).
I do wonder if digital scholarship might incite some of the compositional practices you describe in programming. Sometimes a change in media can really shake things up. On the flip side, we don't need to be increasing the production of scholarship. We already have a glut! What we do need is to change the dynamics of scholarship, whether that means digital or not, though obviously I think it means digital.
Meanwhile I think your proposition of faculty writing in parallel to be a radical one. Of course we produce essay collections somewhat in this way, but here you're talking about something much more collaborative. The tough thing would be to find a half-dozen scholars in the humanities who would be willing to subordinate their differences to a common goal. Of course this happens all the time in virtually every other walk of life, but humanities professors are wired that way.
I think that's one of the major obstacles we face in building digital, collaborative scholarly communities.