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.
This article takes me back to a previous job and one of my co-workers. He was fanatic about removing all 'noise' from his office. His PC being the most evil of all noise makers.
He went to the trouble of locating a 6V power source in the PC and then rewiring the fans from their 12V source to the lower power.
The PC was also wrapped in various forms of egg crate foam to reduce vibration and further dampen noise.
When he started complaining about the flourescent lighting in the building we had to warn him that no re-wiring was allowed!
Wil Wheaton should be on The Tick.. as Wesley Crusher. Then the Tick can finally kill Wesley, and when Wil goes to Star Trek conventions, all the people with "Die Wesley" buttons will be behind the times.
Wesley's dead, dude.
...well-designed software still needs clarifying comments.
Any programmer knows that commenting your code is very helpful. I have written small programs for myself without comments. Now when I go back to them, it is very hairy to know what I was thinking and what it is supposed to do at that time. Comments are also like road signs. They help you understand what the program is are doing, and it is executed. Just ask any hardcore programmer, they will agree. Thanks for the insight.
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?
I take it that you haven't installed XP yet.
-----
Free P2P Backup, Windows & Linux
Because "software engineering" (I hate that name, its programming gadammit) is not primarily implementation. Building a bridge requires very litte groundbreaking design: you take a typically take a known bridge concept, and specialize it for the terrain. The tough part is getting it implemented on time and in budget, with tons of logistic hurdles, and avoiding material disaster.
Programming on the other hand is a continuous design process. Implementation is a non-problem, its an ongoing architecture process. (Imagine trying to design a 20 mile long building with 7-10 architects, each with their own unique style)
On top of that, its all non-visual. An architect can look at rendered pictures of what he is designing to get an intuitive feel for its correctness, whereas a programmer must form his image without the benefit of evolved human spacial perception.
Requirements analysis for a bridge is so simple a child can grok it: "something i can walk over the river on". For your typical programming job requirements are much more nebulous: the customer doesnt really know what they want half the time (but theyll know it when they see it).
The whole analogy between Contruction Engineering and The Art of Programming is flawed, otherwise a completed contruction project would be a 40 foot high stack of blueprints that are suppossed to solve a problem that nobody fully understands.
If making a complex program is anything like putting up a large building, then we shouldn't be suprised if most programs are seriously flawed. We've only been doing software engineering for a few decades (somewhere between 1 and 12, depending on how you define the concept). Builders and architects have been honing their skill set for for several thousand years. And they still screw up occasionaly. You can argue that such failures are tragic, but are necessary for engineering to advance.
Now that the famous pencil trick isn't an option for would-be AMD overclockers
What exactly is this famous pencil trick?
(don't bother modding up for a stupid question, just bear with my ignorance and maybe someone can clue me in?)
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
The construction analogy is not perfect (no analogy is) and you can argue that it's seriously flawed. But I see one point of similarity that's hard to avoid: reducing all of software creation to "programming" is as simplistic as reducing all construction to masonry, carpentry, and welding.
Star Trek X? Does that have David Duchonovy as the captain who interrogates every alien race they encounter on the suspicion they abducted his sister?
So when I say I dont believe that, I am being honest. All the following rant is based upon what I have experienced "in the trenches", so to speak. Mayhaps there is an more idealized place in the world where i am wrong (but I doubt it).
I've never met a "Software Engineer" who was an "Integrator" who did anything usefull without writing code. Those ones who did not know how to were absolutely useless. Those that did know how but did not implement were continuously running into the impermeable wall of "Reality Check" when they had to be informed that their snooty design couldnt work.
Any decent implementor on the other hand, had to be a designer/integrator almost by definition, becasuse there were never any rigourous enough requirements to be a tunnel visioned "implementor". Getting requirements that fine grained is apparently equivalent to writing the code.
If you are a high-level code "Architect" who thinks that implementing involves solving the same old simple subproblems, then you havent been reusing code very well. Check your abstraction level and start over.
You will find the truth: Software design *is* software implementation. There are no "Software Engineers", there are only Programmers.
If you draw a pentagon on the surface of the chip with a pencil, then your processor becomes invincible, and runs at 666 GHz. This is also known as the "pentagram of protection" trick.
Depending on how successful Spiner is in his negotiations, maybe the the movie will open with Data's severed head on a table.
They tried that.
It didn't work.
:-P
It's worth noting that a properly-designed page should render reasonably well in any browser, to the limit of the browser's capabilities. Try calling up the page given here in Lynx, for instance; I wouldn't be surprised if it renders properly in Lynx (sans images, of course).
If your browser doesn't render pages properly, you might want to consider upgrading to a better browser, one that properly implements the published standards.
20 January 2017: the End of an Error.
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.