On Writing and Software Engineering
Jan. 11th, 2011 10:41 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
deirdreI started programming for a living before there were a lot of formal methods in widespread use, though they were coming along. Then I got on some projects where it seemed to be "design all the time and could we please frakkin' write something already?"
One time, I broke. I was in a meeting, mocked up a prototype while everyone else was hashing things out -- because I was bored. Spent a week writing it (in C). Three weeks later, it was in production. It solved too many problems. :) Created a couple small ones in remote locations (as it was, unfortunately, a bit less efficient on a high-latency network, but that was a function of what was possible). No one else was even really ready to discuss what the parameters were, they would have taken months.
Flow charts -- well, I could stand making a page of them. Secretly, I hated them, but it was so impossible to admit that in front of other people because they were so "standard."
Then I had a boss who recognized that I loved doing and wasn't so big on the big picture organizing because it would make me chew through the straps. I had an innate sense of organization, but spending a lot of time in meetings and so forth, well, it really wasn't me, let's leave it at that. Said manager introduced me to a book. It is, to me, the most useful book about organizing information I've ever read. It's Tom DeMarcon's Structured Analysis and System Specification.
Sounds dry as hell, right? Well, it's not going to win any thriller bestsellers, that's for sure (though it is more interesting than 99% of what I've read about software), but it said two things that had me perk right up:
1) The most important thing to plan is how information transforms and flows through the system from a bottom-up perspective.
2) A flow-chart is inherently top down.
In other words, the method I instinctively already disliked was wrong. (Edited to add: flow charts can be useful, actually, just not at this particular phase. One way they can be useful to a writer is comparing two different interpretations of a scene: what structural changes would need to follow if this happened vs. that happened?)
The following year, after changing jobs, I was working as a database administrator for a large Japanese manufacturer. They had a complex software system they'd paid millions for. It was broken in some critical ways, but the contracting firm didn't see it that way. I went and wrote down how every piece of information flowed through the multi-machine, multi-database, multi-OS system -- and found where there were disconnects. These were easy things to resolve -- if you saw them. After one pointed meeting where I laid it all out (amusing the Japanese execs to no end), the contractor saw the light and it got fixed. And lo, the system worked. There would never have been so much unhappiness on that project if they'd looked first at how the data flowed through the system. Instead, it was a bunch of disconnected parts that worked fine on their own but didn't work together.
Now, consider a story. A scene has information -- characters, settings, things people are doing, events. A scene has movement. Things change. This is all information. Further, all the scenes do need to work together, and there's got to be some kind of flow -- even if it is unconventional -- through the work.
Thus, it dawned on me that my organizational problem of how to manage my larger work, e.g., a novel, was the same as how to handle a larger software project: look at the points of transformation. Work from there.
Now, I'm a pantser. I am a serious pantser. I don't do any of this until I have a first draft.
I developed a few conventions. For example, if there were multiple viewpoints, then the bubble for the scene's actions would get the viewpoint character's color. If it's a single viewpoint character (like first person), then the background color would be based on who the scene was mostly about.
I haven't found an example I felt like posting yet, but I may go find one.
One time, I broke. I was in a meeting, mocked up a prototype while everyone else was hashing things out -- because I was bored. Spent a week writing it (in C). Three weeks later, it was in production. It solved too many problems. :) Created a couple small ones in remote locations (as it was, unfortunately, a bit less efficient on a high-latency network, but that was a function of what was possible). No one else was even really ready to discuss what the parameters were, they would have taken months.
Flow charts -- well, I could stand making a page of them. Secretly, I hated them, but it was so impossible to admit that in front of other people because they were so "standard."
Then I had a boss who recognized that I loved doing and wasn't so big on the big picture organizing because it would make me chew through the straps. I had an innate sense of organization, but spending a lot of time in meetings and so forth, well, it really wasn't me, let's leave it at that. Said manager introduced me to a book. It is, to me, the most useful book about organizing information I've ever read. It's Tom DeMarcon's Structured Analysis and System Specification.
Sounds dry as hell, right? Well, it's not going to win any thriller bestsellers, that's for sure (though it is more interesting than 99% of what I've read about software), but it said two things that had me perk right up:
1) The most important thing to plan is how information transforms and flows through the system from a bottom-up perspective.
2) A flow-chart is inherently top down.
In other words, the method I instinctively already disliked was wrong. (Edited to add: flow charts can be useful, actually, just not at this particular phase. One way they can be useful to a writer is comparing two different interpretations of a scene: what structural changes would need to follow if this happened vs. that happened?)
The following year, after changing jobs, I was working as a database administrator for a large Japanese manufacturer. They had a complex software system they'd paid millions for. It was broken in some critical ways, but the contracting firm didn't see it that way. I went and wrote down how every piece of information flowed through the multi-machine, multi-database, multi-OS system -- and found where there were disconnects. These were easy things to resolve -- if you saw them. After one pointed meeting where I laid it all out (amusing the Japanese execs to no end), the contractor saw the light and it got fixed. And lo, the system worked. There would never have been so much unhappiness on that project if they'd looked first at how the data flowed through the system. Instead, it was a bunch of disconnected parts that worked fine on their own but didn't work together.
Now, consider a story. A scene has information -- characters, settings, things people are doing, events. A scene has movement. Things change. This is all information. Further, all the scenes do need to work together, and there's got to be some kind of flow -- even if it is unconventional -- through the work.
Thus, it dawned on me that my organizational problem of how to manage my larger work, e.g., a novel, was the same as how to handle a larger software project: look at the points of transformation. Work from there.
Now, I'm a pantser. I am a serious pantser. I don't do any of this until I have a first draft.
I developed a few conventions. For example, if there were multiple viewpoints, then the bubble for the scene's actions would get the viewpoint character's color. If it's a single viewpoint character (like first person), then the background color would be based on who the scene was mostly about.
I haven't found an example I felt like posting yet, but I may go find one.