Reading http://www.bofh.org.uk/articles/2003/08/01/the-fine-art-of-complexity-management last night, it occurred to me that a lot of the programming I'd been doing (and seeing) on the Disc was very similar in approach to some of the things and working practices I learnt in the theatre.
There's an awful lot of stuff going on, a great deal of thought and care goes into each performance - each instance of that implementation of the underlying text, if you want to put it in programming terms. You need to think not just about "what does this mean, what is it trying to do", but about "how does this relate to what's going on? How can I make it accomplish the goals I want it to?" It's not sacred, it's not anything wonderfully special that can't be touched, it's just something someone wrote for a purpose, and left there for the next guy to come along and use, and if it's anything non-trivial you'll have a lot of fun learning the quirks and intricacies of it.
All that work beforehand, and the audience doesn't see it - all they see is the actors and the effects. They don't see the lighting technician in his box, or the notes he made on his copy of the script, or the crossings-out and revisions. Whether the sound guy uses minidisk or mp3 or vinyl, or whether he has an assistant with a stage weight and a tin sheet, is entirely irrelevant to the audience's experience. (For an ideal audience, anyway. In real life, you'll always get someone who can tell the difference.)
You don't see the kludges and the gaffer tape, you don't realize that the reason the leading lady always stands like that is because her dress is held together at the back with safety pins.
We do much the same programming, abstracting out the complexity, and providing an easy interface to the important part, the story.
There's an awful lot of stuff going on, a great deal of thought and care goes into each performance - each instance of that implementation of the underlying text, if you want to put it in programming terms. You need to think not just about "what does this mean, what is it trying to do", but about "how does this relate to what's going on? How can I make it accomplish the goals I want it to?" It's not sacred, it's not anything wonderfully special that can't be touched, it's just something someone wrote for a purpose, and left there for the next guy to come along and use, and if it's anything non-trivial you'll have a lot of fun learning the quirks and intricacies of it.
All that work beforehand, and the audience doesn't see it - all they see is the actors and the effects. They don't see the lighting technician in his box, or the notes he made on his copy of the script, or the crossings-out and revisions. Whether the sound guy uses minidisk or mp3 or vinyl, or whether he has an assistant with a stage weight and a tin sheet, is entirely irrelevant to the audience's experience. (For an ideal audience, anyway. In real life, you'll always get someone who can tell the difference.)
You don't see the kludges and the gaffer tape, you don't realize that the reason the leading lady always stands like that is because her dress is held together at the back with safety pins.
We do much the same programming, abstracting out the complexity, and providing an easy interface to the important part, the story.
no subject
Date: 2005-10-05 03:54 pm (UTC):)
no subject
Date: 2005-10-05 03:57 pm (UTC)Object-oriented programming is itself an abstraction, especially when it comes to things like VOBs. I remember trying to solve my first "simple" terrains bug, and having to delve deeply into three or four files (with an additional inherit or two each) that were seemingly unrelated, to solve a bug with what looks like a room.
Performers need to know their art, and their art is an abstraction. The audience sees a seamless performance, and if they don't, we fine-tune :)
no subject
Date: 2005-10-05 04:11 pm (UTC)