Slashdot Mirror
Slashback: Crusher, Satellites, Silence
That fetid odor continues to rise. cconnell writes "In September, Slashdot and Developer.com were kind enough to publish an article I wrote titled Most Software Stinks!. The article generated 748 comments on slashdot, making it one of the most active stories in recent months. Here is a follow up piece I wrote which responds to some of the comments."
Silence, fool! The Panther! writes "Here's an article I wrote that shows step by step how to achieve some measure of silence in my home office. It's different from most in that it approaches damping existing hardware rather than buying new. Some ideas were suggestions of Slashdot readers from a previous article. Lots of photos for the reading-impaired." Hemos may have been going for a rather normal-looking but quiet PC, but The Panther sure isn't.
Step 39: With your dremel strapped to the hamster, gently nudge the billiard ball ... Now that the famous pencil trick isn't an option for would-be AMD overclockers, more complicated means have been found to unlock and reclock. Carlos writes: "I saw that you have a scoopage on the unlocking of the Athlon XP by Tom's Hardware and there is a better and more reversible way by VR-Zone."
200 years is a long time even for a Congressman. Michael H. writes "Woohoo! Congress has given a $30 million shot in the arm to the Pluto-Kuiper Belt mission, previously feared canceled. CNN story here. There's still no guarantee that it won't be canceled later, but at least Congress is listening to the fact that it would take ~200 years for the next window if we missed this one."
Hey, that guy's too old to be a kernel maintainer -- we'll make him an actor. bahamat wrote yesterday: "I'm hanging out in Wil Wheaton's chat room (#rfb on undernet) and he's just announced that he's going to be making a cameo as Wesley Crusher in the new Star Trek X." Apparently, the news hit quite a few readers, too -- and for those who haven't, check out our interview with Wil. Maybe he'll get to be on The Tick, too.
...did you do to that webpage? The one about the quiet PC. All the text is there but all the images are scrunched up, overlapping, in the upper left hand corner. I'm interested but not so much that I'm going to download and fix this braindead web design.
324006
Allow me to point you to Wil's previous comment on the interview.
Summary: he was joking.
When this story was first posted, an alert Slashdotter pointed out that the 200-year figure was not generally agreed upon, because using Venus as the gravity slingshot (actually, it's more of a trebuchet , isn't it?) would allow launching a mission in any year. Plus, there's no real compelling evidence that the atmosphere will freeze out during the Plutonian winter.
Don't get me wrong—I do want to see a mission to Pluto in my lifetime, but I just want to get the facts straight. Anyone with supporting data either way?
If all this should have a reason, we would be the last to know.
Mr. Connell makes the excellent point that some engineering problems -- anything from difficult bridge designs to going to the moon -- are every bit as complicated as the software we produce.
... well, everything. None of the early stuff is quite good enough yet. Don't fool yourself into thinking Linux is the end of the road in operating systems, for example. Software is immature. We're forging ahead on every front at once, before the basic pieces are in place, and this will necessarily strain the industry. Once the infrastructure settles down, once we don't need as many projects going on, natural consolidation will lead to more people on each team and better quality.
I agree.
However, it's important to consider one thing -- how many bridges are built every year? How many have as many challenges as the Clark Bridge? Not many, certainly. How much software is written in a year?
If I had, say, three years and millions of dollars to design every piece of software I write, with lots of subordinates double-checking everything I do, well then my code would be perfect as well. The fact is, however, that we write an awful lot more software every year than we build engineering feats, and that has a lot to do with the quality issue. If every program were written over a period of years by a dedicated team of engineers backed by serious budgets, there wouldn't be nearly as much crappy software. However, there's a lot more software hacked together by one guy working out of his garage -- and I daresay if we built bridges that way, a lot of them would fall down.
"So," says the critic, "we just need to design software as seriously as we design bridges."
Not really, I respond. For one thing, our need for software is *really high* right now. We need tons of it -- web browsers, and word processors, and operating systems, and filesystems, and
When civil engineering was immature, a lot of bridges fell down, too, before everything was worked out. I doubt too many people stood around saying "You idiots! Every wagon we design works! Why not bridges?!?" At that time, building bridges was so difficult that it was amazing it ever worked. If it fell down, you just built it stronger and hoped for the best. We've come a long way since then.
I think we're at a similar point in software engineering. Sure, some of our stuff really sucks, but it's such a new field that it's really amazing that we get anything done at all. I frankly think it's unreasonable to expect the field to have matured overnight.
Maybe I'm just not as picky as some people, maybe the cynicism of old age is setting in. But I really don't feel that there's any need for a "Grab the torches and pitchforks! We improve software quality *now*!" movement. Things are getting better, and they will continue to as the market matures. Maybe we should just let it.
ZFS: because love is never having to say fsck
you use a fine pencil, like a .5mm mechanical, to short the L1 bridges on top of the processor. This allows you to change the multiplies on the cpu in the bios of your motherboard if it supports it (my kt7a-raid does). The newer athlon XP's have some changes that make this impossible to do with a simple pencil.
Lawyers, MBA's, RIAA? A jedi fears not these things!
I worked as a Civil engineer for 7 years before switching over to IT fulltime 5 years ago. I am afraid that all these analogies are wrong. A *LOT* of engineering projects run over budget and *MOST* of them run over time. The only real difference is that most clients don't come to you halfway through building the bridge and tell you to use a suspension system instead of plain old columns. (If they do, the engineer politely tells them to go away as they should have come up with those ideas during the design phase)Therein lies the biggest problem facing software engineering. The client always, repeat always wants to add or change features as you go along. This is OK if it comes during the design phase and not the build phase which is unfortunately when most clients first really realise what they want.
fetid: having an offensive odor
fetid odor: an odor having an offensive odor
I don't know much about the actual building of bridges but the Bridge Builder game gave me a much deeper appreciation of the physics behind bridges. Plus, it was a fun way to fritter away a few hours on a rainy afternoon. Check it out.
DISPLAY display;
Rememeber, it's the code that actually does the work. Comments should explain what's not obvious in the code, but should NEVER substitute for well laid out, well written, and easily readable code. And comments shouldn't try to educate the programmer. For instance, back in the CGA card age, I wrote a function for drawing lines, with the following prototype:
void bresenham_line(int x1, int y1, intx2, int y2)
I put no comments in the function code itself. If a programmer has never heard of Bresenham's algorithm, he has no place in maintaining graphics code. The same is valid for a large number of well known algorithms, which are so basic and have been implemented so many times that all programmers should know them.
It may be hard for the beginners, but you are a beginner only once. That's why I prefer to write C programs in Unix, instead of Java, or VB programs in M$-Windows. Once you learn how to use industrial grade tools, you won't be satisfied with hobbyist tools anymore.
But, unfortunately, this is not always possible. Programmers are often seen as people who can do any maintenance in any sort of software. And that's where an over-abundance of comments may help. It's not that those comments are really necessary for a competent programmer to understand the code, they are actually doing a totally different job: they are trying to educate a financial programming expert in the basic concepts of digital signal processing (for example).
In the end, I believe that's one of the main reasons why so many programs stink. They were done by people who knew how to program, but didn't have but the vaguest idea about what they were programming for.