4 ms·

We need to remember that computers are young. Really, really young. The invention of the first-ever electronic digital computer is still an event within living

We need to remember that computers are young. Really, really young. The invention of the first-ever electronic digital computer is still an event within living memory. This can be hard to remember. Especially when you yourself are young, you're used to thinking of things that are even slightly older than you as eternal. (When you reach my age, and you are beginning to have colleagues who literally weren't alive during formative periods of your early career, you get a deeper appreciation for the fact that people -- including yourself -- have these horizons.) For example, I did graduate work on lasers, and I built my work on top of a great deal of earlier work, so I tend to think of lasers as things that have been around for a long time. But the laser isn't very old. It turned fifty this year. Many of my friends are older than the laser. Many of its early pioneers are still wandering around. Look up the early years of engineering. Read certain chapters of the excellent Structures, or Why Things Don't Fall Down, or for a more personal view check out Chapter 20 of Mark Twain's Life on the Mississippi: http://www.classicreader.com/book/2886/21/ http://www.classicreader.com/book/2886/21/ The early history of tall buildings is the history of towers falling down. The early history of modern bridges is the history of bridges collapsing. The early history of steam-powered transportation is the history of boiler explosions, especially in the USA, which had a reputation for quick-and-dirty mechanical hacks as far back as the early 19th century. These situations took decades to change... or longer. Sometimes an order of magnitude longer. And, crazy ideas about the Singularity notwithstanding, technology proceeds at a human pace. Right now, we're still at the point where substantial portions of the world population don't even have access to a computer (although the smart phone promises to change that). Very few people know how to program at any level. And that is the major issue facing programmers today, as it has been since the microcomputer was invented in the 1970s: There is more value in spreading the temporary hacks around more widely and cheaply than there is in inventing more permanent and solid stuff. Until we can meet the insatiable and growing demand for poor implementations of 1970s-era computing technologies, there's really no time or money for anything else. This condition is probably temporary, but when I say "temporary" I may still be talking on the scale of decades.

ghotli 16y ago
Comments with supporting book suggestions. This is the kind of comment I can get behind.
- notaddicted 16y ago
  I'll second the recommendation for J.E. Gordons's Structures. The first and last chapters are wistful and heavily editorialized, but everything in between is excellent.
demallien 16y ago
No. Although your point about the youth of the system involved being a critical determinant to it's reliability is correct, you make an error in naming that system as "computers". "Computers" are reliable these days. We rarely have design problems with the actual hardware (ok, sometimes we have higher than desired failure rates, but most of the time, computers these days are very reliable). They function pretty much as we expect them to. As proof, they are so reliable that when we have a bug in our programs, we no longer even think to point the finger at the hardware. Instead, we point the finger at the software (though in too many cases devs still tend to point the finger at other people's code, when they should look at their own code first - it is the youngest, and hence least reliable, as a general rule). The problem is software. I seem to recall pg writing an essay about this - we aren't making copies of something that already exists, we're making new things, things that have never even been dreamt of before. Of course we're going to have problems. I've watched in amazement as Rails has gone from a not-particularly-reliable framework to something relatively solid and flexible in a matter of years. MacRuby has gone from a dream to one of the best ruby implementations out there over the same sort of time frame. The list could go on and on. But getting reliability out of a system takes time. As a rough heuristic, I think you could say that you need about a year of catching and fixing bugs in a product from the time that you stop adding features for every year that the product took to develop. If you add features, the new parts won't be right until another year has gone by (although hopefully unit tests should prevent regressions in the existing code). Of course, in a shop with sloppy coding standards, you may never get a stable product out the other end, but I think that most competent engineers these days know the techniques that will give a reliable system - verifying inputs to APIs, Unit Tests, documentation, specs.
- RyanMcGreal 16y ago
  >We rarely have design problems with the actual hardware Hard drives, still the main data storage hardware in most computers, are utterly unreliable.
  - blasdel 16y ago
    But not for the reasons you'd think -- mechanically they're incredibly reliable these days, even when violence is done to them. What sucks now is the software running on the embedded drive controller, especially on the most recent highest-capacity drives available at any one time -- the most common bug is for the whole drive to just stop responding for several seconds. There is still one type of hardware error causing problems -- single-bit corruption errors. They're much less likely than they used to be, and the drive will catch them with a checksum when read back, but capacities are so high that the probability of hitting one when reading back a full drive is nearly %100. This makes RAID-5 and other parity-based striping systems almost completely unviable these days -- you'll never be able to rebuild the array from n-1 drives without hitting a single-bit error. And because of the software bugs in drives, they drop out for no reason all the time forcing you to rebuild the array (which then fails because a cosmic ray caused a single-bit error). SSDs won't save you either, they have even more classes of software bugs present in their embedded controllers.

ghotli 16y ago

Comments with supporting book suggestions. This is the kind of comment I can get behind.

notaddicted 16y ago
I'll second the recommendation for J.E. Gordons's Structures. The first and last chapters are wistful and heavily editorialized, but everything in between is excellent.

demallien 16y ago

No. Although your point about the youth of the system involved being a critical determinant to it's reliability is correct, you make an error in naming that system as "computers". "Computers" are reliable these days. We rarely have design problems with the actual hardware (ok, sometimes we have higher than desired failure rates, but most of the time, computers these days are very reliable). They function pretty much as we expect them to. As proof, they are so reliable that when we have a bug in our programs, we no longer even think to point the finger at the hardware. Instead, we point the finger at the software (though in too many cases devs still tend to point the finger at other people's code, when they should look at their own code first - it is the youngest, and hence least reliable, as a general rule). The problem is software. I seem to recall pg writing an essay about this - we aren't making copies of something that already exists, we're making new things, things that have never even been dreamt of before. Of course we're going to have problems. I've watched in amazement as Rails has gone from a not-particularly-reliable framework to something relatively solid and flexible in a matter of years. MacRuby has gone from a dream to one of the best ruby implementations out there over the same sort of time frame. The list could go on and on. But getting reliability out of a system takes time. As a rough heuristic, I think you could say that you need about a year of catching and fixing bugs in a product from the time that you stop adding features for every year that the product took to develop. If you add features, the new parts won't be right until another year has gone by (although hopefully unit tests should prevent regressions in the existing code). Of course, in a shop with sloppy coding standards, you may never get a stable product out the other end, but I think that most competent engineers these days know the techniques that will give a reliable system - verifying inputs to APIs, Unit Tests, documentation, specs.

RyanMcGreal 16y ago
>We rarely have design problems with the actual hardware Hard drives, still the main data storage hardware in most computers, are utterly unreliable.
- blasdel 16y ago
  But not for the reasons you'd think -- mechanically they're incredibly reliable these days, even when violence is done to them. What sucks now is the software running on the embedded drive controller, especially on the most recent highest-capacity drives available at any one time -- the most common bug is for the whole drive to just stop responding for several seconds. There is still one type of hardware error causing problems -- single-bit corruption errors. They're much less likely than they used to be, and the drive will catch them with a checksum when read back, but capacities are so high that the probability of hitting one when reading back a full drive is nearly %100. This makes RAID-5 and other parity-based striping systems almost completely unviable these days -- you'll never be able to rebuild the array from n-1 drives without hitting a single-bit error. And because of the software bugs in drives, they drop out for no reason all the time forcing you to rebuild the array (which then fails because a cosmic ray caused a single-bit error). SSDs won't save you either, they have even more classes of software bugs present in their embedded controllers.