5 ms·

This simple and completely true statement never ceases to fascinate me: > In short, as an industry, we all stink. We really do stink and we as an industry are

by kahawe 16y ago

This simple and completely true statement never ceases to fascinate me: > In short, as an industry, we all stink. We really do stink and we as an industry are nowhere near a state where there are any real standards and best practices in place like e.g. when building a skyscraper or a road. Those are fairly to pretty damn complicated tasks and there is so much knowledge, experience and best practice involved and everyone in the construction industry (should..) knows them and when it is done you can have it checked and certified that it was well built and won't crumble the next day. I don't think anything like this even remotely exists in IT. We have a lot of RFCs describing protocols and what not but nobody can really objectively certify your serious-business software as well-built or can verify whether you applied even the smallest best practices or common sense guidelines because there are so many almost religious wars being fought over completely minor advantages and dis-advantages which simply do not matter on a global scale. And far too many really, really actually bad programmers just get away with their mess or horrible, insane code.

twymer 16y ago
I think the use of some of these strategies mentioned are what should be best practice. Code coverage checkers and code analysis tools, most specifically.
mechanical_fish 16y ago
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.
perlgeek 16y ago
Many "real world" building projects far exceed the originally estimated cost; some of them are not very stable at all, and scale badly when put under strain that wasn't originally envisioned. Just one link: http://en.wikipedia.org/wiki/Scottish_Parliament_Building#Timeline_of_cost_increases http://en.wikipedia.org/wiki/Scottish_Parliament_Building#Ti... Software development is not nearly perfect, but neither is engineering of "real" buildings. My farther in law is a civil engineer, and when I told him that I believed that engineering in his discipline worked much better than in the software industry, he just gave me a disbelieving look and called me naiive.

by kahawe 16y ago

twymer 16y ago

I think the use of some of these strategies mentioned are what should be best practice. Code coverage checkers and code analysis tools, most specifically.

mechanical_fish 16y ago

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.

perlgeek 16y ago

Many "real world" building projects far exceed the originally estimated cost; some of them are not very stable at all, and scale badly when put under strain that wasn't originally envisioned. Just one link: http://en.wikipedia.org/wiki/Scottish_Parliament_Building#Timeline_of_cost_increases http://en.wikipedia.org/wiki/Scottish_Parliament_Building#Ti... Software development is not nearly perfect, but neither is engineering of "real" buildings. My farther in law is a civil engineer, and when I told him that I believed that engineering in his discipline worked much better than in the software industry, he just gave me a disbelieving look and called me naiive.