Was it really important?
May. 4th, 2008 09:01 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mbarkerFor some reason this morning, I was meditating on the time I corrected Michael Jackson. I think maybe it was Rolanni's plaintive post about people who mistreat shared printers that reminded me of it.
Oh, not the media star. No, this was Michael Jackson of Software Engineering -- quite famous in our little neck of the woods, and a very nice speaker. But last December, I sat up near the front at the conference and he was giving a presentation. In his example he happened to mention the notion that elevator brakes are applied when there is a problem. I shook my head, and he noticed, and stopped to ask if there was some problem? I told him to go ahead, that it wasn't important at this point, but I would explain when we got to questions and comments.
Sure enough, when we got there, he did ask about it. I explained that as I understood it, success of the Otto elevator depended on the fact that the brakes were applied by default, and only released temporarily when the desired conditions were met (door closed, power on, etc.). This is how Otto could stand on the elevator and invite people to cut the power, cable, or otherwise attempt to make it drop -- and be sure that it wouldn't. Because as soon as the conditions that release the brakes are removed, they go back on. So there are a few conditions that release the brakes, and many that leave them tight. And in case of something unexpected, well, the default is for the brakes to be applied.
It's interesting because Michael was talking about how to make software that meets requirements. One of those requirements, of course, is that the elevator stop sometimes. But doing it the positive way -- apply the brakes when these conditions are met -- is prone to failure because people forget something (e.g., what about an earthquake? Do we apply the brakes?). Doing it the negative way -- the brakes are on except when certain conditions are met -- may leave the elevator locked somewhere on occasion, but as an error condition, not falling is a whole lot better than falling.
There's a principle somewhere in there -- along the lines of do no harm, look before you leap, and similar adages. Software should only do something when conditions are met? Not sure, but I still think it was important enough to interrupt Michael. After all, I would rather have a car that sits there in odd circumstances than one that runs away. But maybe that's just me.
Oh, not the media star. No, this was Michael Jackson of Software Engineering -- quite famous in our little neck of the woods, and a very nice speaker. But last December, I sat up near the front at the conference and he was giving a presentation. In his example he happened to mention the notion that elevator brakes are applied when there is a problem. I shook my head, and he noticed, and stopped to ask if there was some problem? I told him to go ahead, that it wasn't important at this point, but I would explain when we got to questions and comments.
Sure enough, when we got there, he did ask about it. I explained that as I understood it, success of the Otto elevator depended on the fact that the brakes were applied by default, and only released temporarily when the desired conditions were met (door closed, power on, etc.). This is how Otto could stand on the elevator and invite people to cut the power, cable, or otherwise attempt to make it drop -- and be sure that it wouldn't. Because as soon as the conditions that release the brakes are removed, they go back on. So there are a few conditions that release the brakes, and many that leave them tight. And in case of something unexpected, well, the default is for the brakes to be applied.
It's interesting because Michael was talking about how to make software that meets requirements. One of those requirements, of course, is that the elevator stop sometimes. But doing it the positive way -- apply the brakes when these conditions are met -- is prone to failure because people forget something (e.g., what about an earthquake? Do we apply the brakes?). Doing it the negative way -- the brakes are on except when certain conditions are met -- may leave the elevator locked somewhere on occasion, but as an error condition, not falling is a whole lot better than falling.
There's a principle somewhere in there -- along the lines of do no harm, look before you leap, and similar adages. Software should only do something when conditions are met? Not sure, but I still think it was important enough to interrupt Michael. After all, I would rather have a car that sits there in odd circumstances than one that runs away. But maybe that's just me.
