The wobbly mountain of abstraction
Apr. 29th, 2003 12:21 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
andrewduckerYou can skip down a bit if you want to miss out on the boring computer bit. The nervous breakdown I had is in paragraph 9. Paragraph 8 if you don't count this one. Which you might not. It's more of a note than an actual paragraph after all.
A few years ago I was instrumental in designing a multi-tier computer system. A multi-tier system is one where each layer is abstracted so that the layers above it don't need to know how it works. So for instance, you'd have an interface layer which dealt with presenting data and accepting instructions, a business rules layer, which took the users input and decided which rules to invoke and in which order and a database layer which the business rules layer used for keeping the information in when it had manipulated it. The interface layer doesn't have to care what the rules do, it just has to be able to tell them "do it" and similarly the business rules don't care if the data is kept in a relational database or on a stack of punch cards.
It's a fantastic way of writing systems without causing massive complexity. The complexity of any one section is confined to its own layer and as long as you keep the communication between layers to a documented standard you can change whole layers out without causing a problem. Imagine it as being like a set of black boxes sending signals to each other - no black box knows what happens inside the other black boxes, they just know that they need to send certain kinds of signals to the other boxes and recieve other kinds back.
The problem, however, is the Law of Leaky Abstractions. The law is simply stated as All non-trivial abstractions, to some degree, are leaky. which tells you nothing useful. For those o fyou that can't be bothered reading the article, what it basically means is that while in theory you may not need to know what's in the black box you're talking to, it can make a hell of a difference if you do.
Take, for instance, an automatic gearbox. There's a nicely abstracted system. Rather than having to deal with the mess of gears and understanding how they work, simply put the car in Drive and let it deal with all the worrying. Except that even with an automatic car, having an understanding of what gears are and how they work means that your ride will be smoother than it is for someone who doesn't understand them. The same is true with computers; while the business rules may work whether the data is stored in a database or on punch cards, you can bet that different code will be more efficient depending on which one you are attached to. Anyone writing an abstracted multi-tiered system is always left wondering "Do I pretend that I don't know what the system is like underneath, and write the best general code I can? Or do I write highly efficient but specific code that will work horribly if the underlying layer changes?"
Anyway, if you read this article here you'll not that in order for a simple operation to occur in the system defined here 46 distinct systems have to function flawlessly. Some of these systems are so tiny that they make neurons look big. Some of them rely on bizarre theories like quantum mechanics. I'm certainy not convinced that there are many people on the planet that could grasp all of the layers and certainly not all of them at the same time. And for something simple to happen they all have to work at the same time. For the system to be reliable they all have to work every single time. How many times a day do you do something in Windows? How often does it break? If there are 47 layers in any one action, then a 1% chance of error in each layer means that there's a 1 in 3 chance that one of them will break during an operation. Even if there's only a 0.1% chance, that's still a 1 in 20 chance that the system as a whole will fail.
Most of you will be using machines that are at least 100MHz in speed. How often do you think about the the meaning of that - that 100,000 times a second the computer performs an action. Let's say that you want the computer to run for a whole second and each action runs through those 46 layers (or 46 layers of different kinds, different operations will go through different layers, but we can take 46 as a reasonable number of operations for a command to affect). And let's say that you want it to have a 99% chance of making it all the way through that second without the machine going wrong on you. A quick play with Excel tells me that each layer can go wrong once every 419710278 times. Or, if each operation occured once a second, they would have to run for 13 years without a crash.
Now, I didn't feel terribly confident that I could write code that worked that well. Worse that that - I was only in control of a few of the layers - I have no control over the language itself, the computer hardware or (most significantly) Windows. I'd consistently hit walls of errors which I could do nothing about because the problem wasn't in my code, it was happening in a layer under the control of Windows. Not only does Windows have bugs, but even if you get them fixed you have no way of telling your customers to also have those fixes, so your code has to constantly work out what kind of system its running on and then perform one of three differerent kind of crash avoidance technique depending on what kind of crash was caused when testing on Windows 95 with Internet Explorer version 3, without the security patch but with Office installed not the international version. Aah, the fun and games we had.
Anyway, the nervous breakdown didn't come from the code. That was just frustrating. The nervous breakdown came when I went to plug in a kettle and realised that real life was just as bad. That when I plugged the kettle in and turned it on I was expecting a huge chain of systems to work, from electricity generators to power carrying services to transformers, converters, local grids, power division systems (how do they make sure the right buildings get the right power? - damned if I know) fuses, sockets and the kettle itself. Not to mention whatever systems provided fuel to the power station (undoubtably complicated in themselves).
Or do you ever wonder how the food gets to your local supermarket. Well, it's largely computerised nowadays, which means that it gets covered in the magazines I read. To save money, everything runs on just-in-time systems, making sure that money isn't wasted keeping days of stocks around. If those computerised systems go down, or there's no fuel, then all major cities in the civilised world are 2 days away from having no food. Which puts them about 4 days away from riots and 6 from cannibalism.
Thankfully, there's all sorts of redundancies built in so that if one set of computers go wrong, the backup systems start up. I believe that if you wanted to take out HSBC's UK operations you'd have to drop a plane on their main datacenter and then a small nuke on the right spot in the Lake District (the underground bunker with the backup datacentre in it is 747 proof - but then so was the WTC). Not only that, but evein if Sainsburies vanished overnight, there's several other supermarkets to take up the slack.
But even so, for a few weeks I felt like everything was made from eggshells. The general feeling that everything was built from complex multi-layered systems that we take for granted took quite a while to fade. Every so often I'll catch a glimpse of it again usually when it's failed, just slightly, to function perfectly.
It's not a nice feeling at all.
A few years ago I was instrumental in designing a multi-tier computer system. A multi-tier system is one where each layer is abstracted so that the layers above it don't need to know how it works. So for instance, you'd have an interface layer which dealt with presenting data and accepting instructions, a business rules layer, which took the users input and decided which rules to invoke and in which order and a database layer which the business rules layer used for keeping the information in when it had manipulated it. The interface layer doesn't have to care what the rules do, it just has to be able to tell them "do it" and similarly the business rules don't care if the data is kept in a relational database or on a stack of punch cards.
It's a fantastic way of writing systems without causing massive complexity. The complexity of any one section is confined to its own layer and as long as you keep the communication between layers to a documented standard you can change whole layers out without causing a problem. Imagine it as being like a set of black boxes sending signals to each other - no black box knows what happens inside the other black boxes, they just know that they need to send certain kinds of signals to the other boxes and recieve other kinds back.
The problem, however, is the Law of Leaky Abstractions. The law is simply stated as All non-trivial abstractions, to some degree, are leaky. which tells you nothing useful. For those o fyou that can't be bothered reading the article, what it basically means is that while in theory you may not need to know what's in the black box you're talking to, it can make a hell of a difference if you do.
Take, for instance, an automatic gearbox. There's a nicely abstracted system. Rather than having to deal with the mess of gears and understanding how they work, simply put the car in Drive and let it deal with all the worrying. Except that even with an automatic car, having an understanding of what gears are and how they work means that your ride will be smoother than it is for someone who doesn't understand them. The same is true with computers; while the business rules may work whether the data is stored in a database or on punch cards, you can bet that different code will be more efficient depending on which one you are attached to. Anyone writing an abstracted multi-tiered system is always left wondering "Do I pretend that I don't know what the system is like underneath, and write the best general code I can? Or do I write highly efficient but specific code that will work horribly if the underlying layer changes?"
Anyway, if you read this article here you'll not that in order for a simple operation to occur in the system defined here 46 distinct systems have to function flawlessly. Some of these systems are so tiny that they make neurons look big. Some of them rely on bizarre theories like quantum mechanics. I'm certainy not convinced that there are many people on the planet that could grasp all of the layers and certainly not all of them at the same time. And for something simple to happen they all have to work at the same time. For the system to be reliable they all have to work every single time. How many times a day do you do something in Windows? How often does it break? If there are 47 layers in any one action, then a 1% chance of error in each layer means that there's a 1 in 3 chance that one of them will break during an operation. Even if there's only a 0.1% chance, that's still a 1 in 20 chance that the system as a whole will fail.
Most of you will be using machines that are at least 100MHz in speed. How often do you think about the the meaning of that - that 100,000 times a second the computer performs an action. Let's say that you want the computer to run for a whole second and each action runs through those 46 layers (or 46 layers of different kinds, different operations will go through different layers, but we can take 46 as a reasonable number of operations for a command to affect). And let's say that you want it to have a 99% chance of making it all the way through that second without the machine going wrong on you. A quick play with Excel tells me that each layer can go wrong once every 419710278 times. Or, if each operation occured once a second, they would have to run for 13 years without a crash.
Now, I didn't feel terribly confident that I could write code that worked that well. Worse that that - I was only in control of a few of the layers - I have no control over the language itself, the computer hardware or (most significantly) Windows. I'd consistently hit walls of errors which I could do nothing about because the problem wasn't in my code, it was happening in a layer under the control of Windows. Not only does Windows have bugs, but even if you get them fixed you have no way of telling your customers to also have those fixes, so your code has to constantly work out what kind of system its running on and then perform one of three differerent kind of crash avoidance technique depending on what kind of crash was caused when testing on Windows 95 with Internet Explorer version 3, without the security patch but with Office installed not the international version. Aah, the fun and games we had.
Anyway, the nervous breakdown didn't come from the code. That was just frustrating. The nervous breakdown came when I went to plug in a kettle and realised that real life was just as bad. That when I plugged the kettle in and turned it on I was expecting a huge chain of systems to work, from electricity generators to power carrying services to transformers, converters, local grids, power division systems (how do they make sure the right buildings get the right power? - damned if I know) fuses, sockets and the kettle itself. Not to mention whatever systems provided fuel to the power station (undoubtably complicated in themselves).
Or do you ever wonder how the food gets to your local supermarket. Well, it's largely computerised nowadays, which means that it gets covered in the magazines I read. To save money, everything runs on just-in-time systems, making sure that money isn't wasted keeping days of stocks around. If those computerised systems go down, or there's no fuel, then all major cities in the civilised world are 2 days away from having no food. Which puts them about 4 days away from riots and 6 from cannibalism.
Thankfully, there's all sorts of redundancies built in so that if one set of computers go wrong, the backup systems start up. I believe that if you wanted to take out HSBC's UK operations you'd have to drop a plane on their main datacenter and then a small nuke on the right spot in the Lake District (the underground bunker with the backup datacentre in it is 747 proof - but then so was the WTC). Not only that, but evein if Sainsburies vanished overnight, there's several other supermarkets to take up the slack.
But even so, for a few weeks I felt like everything was made from eggshells. The general feeling that everything was built from complex multi-layered systems that we take for granted took quite a while to fade. Every so often I'll catch a glimpse of it again usually when it's failed, just slightly, to function perfectly.
It's not a nice feeling at all.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2003-04-28 06:28 pm (UTC)Hmm, I lost you right about here. You seem to be saying that levels of abstraction make it more likely that code will have bugs, because the more levels there are, the greater a chance there is that one of them will screw up. But bugs aren't randomly distributed in code -- they happen in places where the programmer has a poor understanding of what's going on. A program with 46 levels of abstraction would be far less likely to have bugs than an equivalent monolithic program, assuming that the abstractions were well-chosen.
no subject
Date: 2003-04-29 02:19 am (UTC)But in almost all applications I've seen, the vast majority of the layers are outside of the programmers control and weren't chosen by the programmer themselves. I've seen incompatabilities between programs and graphics drivers - what programmer gets to choose the grtaphics driver on the clients machine? It's another layer which you have no control over and might go wrong when things run.
I agree that it doesn't happen very often, and it's probably a lot more reliable than if I had to write the graphics drivers myself, but it's still another step going on in the process. I was more trying to get across the sheer scale of how much goes on in a computer at any one time and my general amazement that it ever works at all for more than a second or two (except on very simple computers), than trying for hard numbers. As anyone can see, after all, computers don't crash all that often any more. Hell, this XP box hasn't crashed in months (though when it did, it was down to the hard drive going wrong - another layer I have no control over other than to throw it away and plug a new one in).
no subject
Date: 2003-04-29 01:11 am (UTC)FYI, the WTC was 707 proof - 747s weren't in production at the time of design. And they never modelled even that with a full load of fuel.
no subject
Date: 2003-04-29 05:12 am (UTC)We're completely technology dependent now. Don't let anyone else kid you otherwise, 'cos it's true. But so what? That's just the way it is. No point in worrying about what *might* go wrong. Worrying about *maybes* is never healthy. Cripes, if you follow that line of thinking to it's conclusion, you'd worry about walking beside roads, because what's to stop a car or bus ploughing into you? Or eating food, because who knows how it's been prepared? (This, incidentally, is what amuses me about vegetarianism - how much food do you really think is not contaminated by meat?) Or using a mobile phone, because we don't know the truth?
Don't panic.
no subject
Date: 2003-04-29 05:17 am (UTC)I'd much rather that people did worry about whether asbestos caused deaths, how much lead should be in our petrol, what effect CFCs have on the ozone layer.
Because that way things might change.
no subject
Date: 2003-04-29 01:07 pm (UTC)Those are perfectly reasonable worries. Worrying that the vastly complex series of events that allows electricity to flow when you turn on a light switch strikes me as rather pointless. Then again, one of the benefits of being as lucky as I am is that I'm absolutely certain that I'll never be in that sort of situation for more than the (at most) couple of hours it takes to fix a power blackout.
no subject
Date: 2003-04-29 01:30 pm (UTC)But neither did Stephen's examples of phones causing damage, walking besides roads being dangerous, etc.... I was responding to that, not elaborating on my original point.
Your point on solar cells is completely correct. I await with interest the South African solar magnifier project, which may produce non-polluting solar power, albeit at the expense of a 10 mile radius of desert.
And the worrying is pointless. I was merely describing the semii-breakdown I had, where I spent ome weeks feeling like I was standing on top of a very delicately balanced mountain of interlinked systems which might fail at any moment. as I said, the chances of it actually going wrong is minute. It was the realisation that there was this complex system running in the background that was vital to my daily life that threw me off balance.
I've not lost power for more than half a second in the last 10 years. But then, I don't live in a thirld world country.
Re:
Date: 2003-04-29 02:48 pm (UTC)no subject
Date: 2003-04-29 02:58 pm (UTC)