Forgot your password?
typodupeerror
Slashback

Slashback: Crusher, Satellites, Silence 241

Posted by timothy
from the greetings-from-superfund-tennessee dept.
Slashback with more on Wesley Crusher; overclocking new Athlons the kindler, gentler way; building silent PCs for the more ambitious; software that stinks; and more -- just read on for the details.

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 discussion has been archived. No new comments can be posted.

Slashback: Crusher, Satellites, Silence

Comments Filter:
  • Wesley Crusher is my favorite character!!!!!

    But quite a few years have past... I hope the SF people can make Wil look young again ;)
  • His channel is going to get quite a slashdotting for this. I hope that the SNR doesn't drop /that/ much.

    Good Luck, Wil!

    Colin
  • Seriously, it would be cool if he was on The Tick, but even better if he was Sweater Boy or something.

    I mean, think about the banter between Wesley Crusher and the Blue Icon of Justice!

    -
  • ...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.
    • 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.
      I'm not the creator of that page, but let me guess...you're using Nutscrape 4.x as your web browser, right? A quick check of the HTML indicates that CSS positioning was used; Nutscrape is brain-dead and doesn't know how to implement CSS positioning (or most other things related to CSS, for that matter). Internet Explorer works properly; Mozilla and Opera should work too (and maybe some other browsers, but those are the ones I know of offhand that implement CSS more-or-less correctly).
      • BillyGoatThree:
        braindead web design.

        ncc74656:

        A quick check of the HTML indicates that CSS positioning was used; Nutscrape...doesn't know how to implement CSS positioning. Internet Explorer works properly; Mozilla and Opera should work too

        So, you're in agreement: It was a braindead web design. "Use my browser or don't view my webpage" is braindead web design. Period. [anybrowser.org]

        • "Use my browser or don't view my webpage" is braindead web design. Period.

          Hey, I wrote this browser where the [IMG] tag makes images blink unless you use the NOBLINK attribute, and the [TABLE] tag turns the rest of the text yellow. I'm the only person using it, but you now have to write web pages to conform to my choice of browser! Ha ha! Bet you didn't see that one coming! Also, I drive a train, and I demand that the highway department install tracks on all the roads I might drive on.

          How about "use one of the browsers which work correctly and are freely available for every OS or don't view my webpage (or half a billion other ones)". "Correctly" being defined as "conforming to standards defined many years ago."

          • How about "use one of the browsers which work correctly and are freely available for every OS or don't view my webpage (or half a billion other ones)". "Correctly" being defined as "conforming to standards defined many years ago."

            Well, since the subject was Netscape's failure to properly render CSS positioning, and since CSS wasn't in the HTML standards of "many years ago," you basically support my position. By the way, did you follow the link I gave [anybrowser.org]?

            • Yes, I'm well aware of the Any Browser campaign. I had their banner on my own web site when I had one up. BTW, it doesn't render correctly in Mozilla. (although it's perfectly readable, of course.)

              HTML 4 was released by the W3C in December 1997 and updated in April 1998. That's three and a half years ago. CSS level 1 was released in December 1996 and CSS2 was released in May 1998. I think three years counts as "many" in the context of a browser that's 6 or 7 years old.
            • Well, since the subject was Netscape's failure to properly render CSS positioning, and since CSS wasn't in the HTML standards of "many years ago," you basically support my position. By the way, did you follow the link I gave [anybrowser.org]?

              CSS1 [w3.org] has been a standard since December 1996 [w3.org], CSS2 since May 1998. Don't give any crap about NS4 being older than the spec because it isn't really true. CSS didn't spring forth from the head of Berners-Lee, NS and MS both helped design the standard. At the time Netscape was pushing their proprietary HTML tags and CSS implementation and didn't bother to implement the standards. NS4 is intentionally broken.

              I do blame Netscape for failing to implement the standards that they helped to create. It's very, very sad that browser implementations are 5 years behind their own standards, keeping web design in the dark ages. Blinking purple text on a blinking starfield background (with flames!!) here I come !!

          • How about "use one of the browsers which work correctly and are freely available for every OS

            Which web browser is that? Specifically, I want to know the one that runs under MINIX.

            Thanks.
        • Netscape 4 doesn't qualify as a browser. Or if you insist that it does, it's a braindead browser.

          I've jettisoned designing for Netscape 4. Considering that my pages work in every other goddamn browser ever created, I consider it an adequate tradeoff.

          Flush N4 down the toilet. (And yes, I run a Pentium 133. I tend to just use lynx.)
        • A quick check of the HTML indicates that CSS positioning was used; Nutscrape...doesn't know how to implement CSS positioning. Internet Explorer works properly; Mozilla and Opera should work too
          So, you're in agreement: It was a braindead web design. "Use my browser or don't view my webpage" is braindead web design. Period.
          Umm...not exactly. Using browser-specific extensions (like IE's marquee tag) would be an example of brain-dead web design. Abusing a browser's scripting capability (such as requiring JavaScript to be able to navigate through a website instead of just using anchor tags...some sites do that) would be another example of brain-dead design. Sticking to published [w3.org] standards [w3.org], OTOH, is usually regarded as a Good Thing.

          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 [microsoft.com] to [browser.org] a [konqueror.org] better [mozilla.org] browser [opera.com], one that properly implements the published standards.

          • Using browser-specific extensions (like IE's marquee tag) would be an example of brain-dead web design

            Not unless that is an added feature that is not required for use of the site, or you provide an alternative feature for use in other browsers.
  • by hansk (107187) on Thursday November 15, 2001 @08:10PM (#2572206) Homepage

    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!

    • (aka "stating the bleeding obvious")

      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.

      Obviously that's going to reduce the fans' cooling performance, with (potentially) baaaaaad effects on your system component lifetimes, even if the magic smoke doesn't escape immediately... :-)

  • Wil Wheaton (Score:3, Funny)

    by sllort (442574) on Thursday November 15, 2001 @08:11PM (#2572212) Homepage Journal
    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.
  • Commented code (Score:5, Insightful)

    by I_am_Rambi (536614) on Thursday November 15, 2001 @08:12PM (#2572214) Homepage
    ...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.
    • Re:Commented code (Score:5, Informative)

      by Rick the Red (307103) <Rick.The.Red@gma i l . c om> on Thursday November 15, 2001 @08:29PM (#2572333) Journal
      No kidding. I once heard some guru pontificate that your source should have three lines of comments for each line of code. I thought that was stupid, until I found myself maintaining other people's code. Then I saw some example code from a database vendor that had three comments for each line of code (mind you, they were explaining how to use a particular feature) and it was as clear as day. It was like someone took the blindfold off. I've tried to totally comment all my code since then, and I've found that I actually write better code. Now, when I have a bug, I look for what the comment says I intended the code to do, then I double-check that the code actually does that; usually the bugs find (and fix) themselves this way. Try it, you'll like it!

      • hear, hear... only those who don't program professionally eschew comments. Anyone's who's had to fix a program under pressure knows that you need all the help you can get..
      • or I could finish it by the deadline...
        • or I could finish it by the deadline...

          HA! You think there will be only one deadline? You will be revisiting that code periodically, either to fix some bug or implement the Feature Du Jour at your boss's boss's behest.

          What do you think costs more time... adding comments now, or trying to figure out what the hell that code is supposed to do later?

      • My rule is that I comment code to say what I _think_ I'm doing. Then if I got it wrong, later I can look at the comment and go 'what?' and be on the alert for implications :)
      • THREE lines of comment for EACH line of code? Ughh! I wonder how you can find the code among all those comments. I have actually seen this comment in a program:

        DISPLAY 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.

      • I really don't know anything about it, but my udnderstanding is that its a way of embedding the documentation and code together. Lyx now supports it. OK, I've exhausted my knowledge of the issue, but I have to do *something* to attone for stripping all the comments out of a pair of 20k Basic programs 20 years ago so I could combine them and have enough space left for data . . .


        :)


        hawk

    • And the best form of comment is one that is the code itself, IMO. Well-chosen variable and function names, for example, or debug messages that clearly state what the F is going on when they're invoked.
      • Word!

        Many times I have looked at other peoples source, read the comments and STILL had to puzzle over awkward syntax and unintuitive variable/funtion names. A few comments are fine, but not a substitute for lucid code.

        Plus, I find that comments can make code harder to read if they break up the continuity of the code structure.
      • Nonono. The point is the comments are to tell you what the code was supposed to do.

        So if the (clearly written) code disagrees with the comments then there is a problem. You now have to figure out whether the code or the comments are correct or both are wrong.

        Whereas without the comments, the clearly written code can be doing the wrong thing and you won't know.
  • The Tick (Score:2, Funny)

    by ocie (6659)
    Will Wheaton as "The Ensign-uator".

    While most characters have only a few great lines that have double meanings, everything he says will be a stream of double and tripple ententres (sp?).
  • In his interview [adequacy.org] he proved to be sensitive in demeanor, kind, and humorous. Wil Wheaton is a gracious net celebrity who has internalized his own Trek character more elegantly than have most former Trek stars.


    His humor is postmodern - his funny is based on the fact that Deliverance and Trek star Wil Wheaton is making the jokes. That doesn't make it bad humor - just self-referential.

    • Wil Wheaton is a gracious net celebrity ...

      Well, yeah, but we just had to rib him with our sweater jokes.

      It's the confusion between the role and the actor. Most people were more upset with the directors and writers who created the role, not Wil himself.

      A reverse example of this effect would be Diane Keaton. In real life, she's not exceptionally smart and witty - that is the role she plays.

      Hollywood frequently demands certain stereotypes. Wesley Crusher was one of those, and Wil Wheaton suffers our jibes because of the stereotype he played, not who he is as a person.

      -
    • I don't have anything much to say here, other than 'hear hear'! I'm not much of a Wesley Crusher fan, but after his enlightening interview, I have to say that I'm a Will Wheaton fan.

      You've done a great job dealing with a tough situation, Will. Kudos.
  • by Tsar (536185) on Thursday November 15, 2001 @08:21PM (#2572287) Homepage Journal
    When this story [slashdot.org] was first posted, an alert Slashdotter pointed out [slashdot.org] that the 200-year figure was not generally agreed upon, because using Venus as the gravity slingshot (actually, it's more of a trebuchet [trebuchet.com], 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?
  • overclocking new Athlons the kindler, gentler way Being an active figure in the kindling community, I'm always looking for the true kindler way to do things. I've been concerned lately that a lot of kindling I'm seeing these days just doesn't cut it compared to the kindling we used to have back in the good old "golden days of kindling". It's good to see that someone is still concerned about doing things the kindler way.
    • ..It's true, they don't make kindling the way they used to. If you don't believe me, try overclocking a K62 to 1.6Ghz - That's MUCH better kindling than an Athlon XP..
  • by Srin Tuar (147269) <zeroday26@yahoo.com> on Thursday November 15, 2001 @08:33PM (#2572351)


    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.

    • I hate that name, its programming gadammit
      Deal with it. "Programming" means designing code. Nowadays a really serious project consists of a lot of pieces that have to work together. Even if the pieces are all coded by the same person, making them work together in a predictable way is a complicated art completely different from that of creating code.

      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.

      • by Srin Tuar (147269) <zeroday26@yahoo.com> on Thursday November 15, 2001 @09:27PM (#2572566)

        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.

        • Careful with your semantics. Engineers are not Engineering.

          You think somebody who tries to architect a software project without understanding the coding issues is stupid? I can't argue with that. Doesn't mean that the same skill are involved in architecting and coding.

          By the same token, construction engineers who don't know how to lay a brick or weld a joint probably don't put up very good buildings. But that doesn't mean every mason or welder knows how to put up a skyscraper.

        • I think he confuses you with his definitions. If I interpret your argument correctly -- which I think I do, because I agree -- but use his terms, there are no programmers, only software engineers.

          That is, he seems to think there's some dead-simple job that you can give to the grunts to do, and doesn't matter if they aren't that clever. You would counter -- there are no such jobs. A job worth doing at all is worth doing well, with a thought of architecture and design.

          Of course, some jobs don't matter as much -- a well defined component can be programmed poorly but to spec and still work. If it has problems, they won't be the large architectural problems that haunt us for decades.

          But then, you can counter -- we are already haunted by architectural problems, because the architects of yore were not prescient. And it takes a good programmer to turn that poor architecture into something good. And good programmers can do that! That is software engineering -- at least how he'd define it.

          Bad programmers may not do as great harm when they are forced into very constrained environments by the definitions of the architect. But we should all know that doesn't lead to great programming -- passable, perhaps, but great programming is better than that -- great programming brings together all the pieces in a way that trancends anything that is possible in a top-down environment. But institutional people don't care about great programming. They make due with passable.

          But the opinion of the original author -- for all the flaws I see in it -- was that software has to be better than passable. So there's two ways: we expect the Engineer-Man to be all-knowing and all-controlling, Ada/Eiffel-style (but with a particular passion for domination), or just maybe we make great programs with lots of great programmers, working together with everyone expected to be smart and have an eye on the overall design. Cathedral vs. the Bazaar, I suppose.

        • > 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.

          I do think implementing involves solving the same old simple subproblems over and over again.

          Why do you think we have patterns? Software tends to follow a set of rules, where the problems are often similar to ones you have tackled before, albeit with a slightly different set of initial tools and/or conditions. e.g. Resource pooling, factories, data warehouses... I could go on....

          Perhaps you could explain what you mean by 'you haven't been reusing code very well'.
    • It could be worse. There are a lot of classic engineers who think that software isn't engineering unless you solve some sort of real-world problem. So AutoCad is a product of Software Engineering, but Linux or Mozilla aren't.
    • Hmm... you obviously don't know much about Civil Engineering...

      Oh well, as a software engineering student (yes, Software Engineering, not Computer Science. When I graduate I will have an Engineering degree), I know lots of Civil, Mech, Comp, etc engineers. Software Engineering is very similar to those other engineering disciplines, software is just easier. You still have to design and build something using lots of math and different techniques. But with software engineering you don't (usually) have to worry about climate, weather, the safety of the people who will use your product, the safety of the people who will build your product, unintended uses of your product, etc, etc, etc (as well as all the things software people have to account for, like traffic, use of the product long after its intended lifetime, and hurricanes. I hate having to make software withstand hurricanes).
      • I'd have to disagree with 'easier'. If you're a civil or mech engineer, then you're working with hundreds of years of physics. If you build a bridge you can calculate exactly how much load that bridge can stand. If you calculate that it isn't strong enough, then you can specify to use more rebar, or stronger concrete or whatever is required to make it strong enough. The documentation on source materials is comprehensive and accurate. If we specify that we need 3200psi concrete, then we can test to ensure that's what we've got.

        When we program software we are often building on sand. Documentation for APIs and libraries are generally awful. Sometimes different versions of the same OS behave differently. Sometimes errors are thrown which are not documented. Sometimes the same error is thrown for two different problems, so the error codes aren't sufficent to diagnose the cause.

        The only way we can test software is by trying everything we can think of to make it fail. If we miss something, then we've got a potential bug. If we become aware of this, then we will add it to our testing schedule. This effectivly makes every software system a unique universe, and means that our testing is always playing catchup.

        There is a reason why the biggest & most successful systems are all 30 years old or more. It's not because the programmers of that era are better, it's just because it has taken a long time to make a system reliable.

    • You say that it takes very little ground breaking design for a bridge, you just drop it in place, however that is hardly the case. You want an example, try the Tacoma Narrows bridge. Lets just take the standard suspension bridge model in drop in it place. What do you mean there are harmonics that will cause it to collapse, oops, oh well. Sure you can take the basic concept and use it as a template (just run the MFC bridge making wizard...) but you should still do a heck of a lot custom design to make sure its suited for the conditions that it will be used in.
    • Building a bridge requires very litte groundbreaking design: you take a typically take a known bridge concept, and specialize it for the terrain.
      Small structures may often be handbook designs, but large bridges and buildings are frequently designed from scratch. There is no one true way to design a skyscraper, any more than there is one true way to design an ERP system.
      An architect can look at rendered pictures of what he is designing to get an intuitive feel for its correctness,...
      [Brief pause for architects to pick themselves up off the floor from laughing so hard.]

      Building designs have more conflicting and poorly-specified human-interface requirements than nearly all software packages. Every aspect of the design -- foot traffic paths, shared workspaces, lighting, ventilation, storage, bathing facilities, and many others -- has a critical impact on both the usability and cost of the building.

      Requirements analysis for a bridge is so simple a child can grok it: "something i can walk over the river on".
      You vastly underestimate the complexity of bridge design. You must know whether the bridge is downstream from a forest, which determines how many trees will crash into it. You must know how much brush gets carried down the river, and how much brush gets caught on the bridge, which determines the lateral loads the bridge will carry in storm waters. You must know what vehicles need to cross the bridge and how often. If the bridge is near the ocean, it must be built of better materials to resist salt corrosion. Likewise if it is in an area where salt is commonly applied to the roads in the winter. If the bridge must carry both pedestrian and vehicular traffic it must have strong barriers to separate the two. If it must carry pipelines and cables, there must be possible to mount them to the bridge. If the waters will rise drastically during a storm, the bridge must not be washed away. The foundations must be deep enough that frost never reaches the bases. The more the temperature swings during the year, the longer its expansion joints must be. It must be able to carry enough traffic, not just today but for at least 50 years into the future. It must be aesthetically, politically, and financially acceptable to numerous conflicting groups of people.
      The whole analogy between Contruction Engineering and The Art of Programming is flawed...
      Both software and structures can be thrown together with little engineering work, but that doesn't make them good.
      ...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.
      They are. Take a look at the engineering documentation for a skyscraper, car factory, or refinery sometime.
      • Thank you for setting him straight. What a dumbass. Perhaps knowing about what which you talk would be good advice for him. My brother is a civil engineer, and just from talking to him, I knew this guy was full of crap. You can't just "render" a bridge and get an 'intuitive' look at it. There is a TON of effort into building something like that.

    • OK, maybe software engineering != construction engineering. But maybe there is a correlation between the history of bridge building and the history of software engineering?

      To be honest , I don't know much about the history of bridge building. When I think of the history of bridge building, I think of different kinds of bridges, including:

      a big log over a stream

      two big logs over a stream

      two big logs over a stream, with other logs lashed on

      cut wood bridge, maybe treated wood, maybe covered (why do those New England bridges have a roof?)

      Rope and wood bridges from Indiana Jones movies

      Stone bridges from England (or even ancient Rome?)

      Modern highway bridges (concrete, supports, standards for the road leading to the bridge, etc.)

      Modern suspension bridges (Golden Gate)

      Drawbridges

      Those cool bridge-on-wheels the army uses.

      etc.

      I don't know what the progression is, how people went from a log over a river to a suspension bridge, or the tech needed to cut wood and make strong rope, or how stone bridges were constructed. I imagine some folks specialized in bridge construction, studying previous designs and learning from contemporary practitioners.

      I do know that it took hundreds to thousands of years to get to the point where there was a science of bridge building, where the strengths and weaknesses of designs and materials were known, written down, and taught. There was also a point where you had to go to a formal school to learn bridge building, and that the government had to certify you as a bridge builder in order for you to design bridges that the public would use.

      We're in the early stages of engineering software. In some places, there's a amateur engineer culture, where some people have an affinity for the stuff, and allowed to do their own thing. In other places, there's a "hire the expert" mentality, where outside masters are brought in to do the design work, and locals are used as cheap labor. In still other places, there's a guild mentality, where educating the next generation and producing a quality product are emphasized. I know of few, if any, places where a modern engineering mentality is maintained, where practitioners are certified to have a certain level of competency, where standards are required, where products are reviewed and analyzed scientifically, where mistakes are published and lessons learned in an institutional manner. Bridge builder all know about Tacoma Narrows, and plan accordingly. Software engineers still write un-commented code in non-portable ways, and expensive "disasters" happen daily.

      Sure, software engineering != civil engineering. But is that due to intractable differences between the two disciplines, or because civil engineering is mature and responsible, while software engineering worships the local experts and laughs at professional rigor?

    • Because "software engineering" (I hate that name, its programming gadammit)
      write complete operational code for a modern satalite(controlls, attitude adjustment, taking pictures, sending data, etc..), and keep it under 640K. Then you'll understand the difference between a software engineer and a programmer.

      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.
      If this is not a goal you try to achieve, then yes, you are just a programmer.

      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.
      you need to look up the word design, think about implementing it, then get out of the business.
      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)
      this is why design standards are used by software engineers, but not programmers like you
      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,
      my grandfather was an architect, and if he was alive right now he would kick your ass for that comment.

      whereas a programmer must form his image without the benefit of evolved human spacial perception.
      this goes back to design standards and practices.


      Requirements analysis for a bridge is so simple a child can grok it: "something i can walk over the river on".
      thats a pretty lame example, and I'm sure it would piss off the engineers that build bridges.
      Its like saying the requirements analys for a program is so simple because anyone who sees the results can grasp all the detail that go 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).
      you froget the four steps:Design, design, design, code.

      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 that statement was true, satellites would fall from the sky every day, man would not have gotten to the moon and back again, computer networks would not exist, etc,etc,etc...
      You sir have no concept of the field in which you are employeed.

      Please scoot back to your PERL and VB programming, and leave the Engineering problems and analogies to engineers.
    • Programming on the other hand is a continuous design process. Implementation is a non-problem

      I totally disagree with the implementation part. That philosophy is what ends up making me wade through (and usually throwing out) countless lines of crappy code because people don't know how to program, or are just doing whatever it takes to get it done.

      You need to be working just as hard while doing the programming itself as during the design phase. Constantly checking what you've done and thinking if there are better ways, making sure that there are no snags or potential problems, generally writing elegant code. That's the hard part.

      its all non-visual

      Again I disagree. If the projects that I worked on were nonvisual we would have died a horrible death. I might be nitpicking on the definition of the word as you meant it, but using diagrams and heirarchical trees of how classes and portions of code interact is usually a very good idea, that gives you the "visual" aspect that you can keep in your mind (and on paper) to remember how everything fits together.

      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

      Absolutely not. I can look at code, and just visually on an aestetic level get a feel as to whether or not it's good code. If it looks like crap, it generally is crap. Once the "prettyness" of the code has been looked at, the actual code itself can be browsed. It is not difficult to tell, just by a quick browse over the code, if the code is good or bad. If you're spending too many lines of code here or there, then you might be overdoing it. If the task of the block of code is to take X input and produce Y output and you're using 200 lines of code to do it, chances are you're not doing it properly.

      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

      I find that many times customers give just as simple an explanation as to what they want :
      "We need to pay our bills online. We need to have it interact with the bank and allow us to have complete control over what gets authorized and denied". Usually there's much more fluff in there, but it's a simple concept that requires quite a lot of work to design.

      However I do agree that there are many customers who don't know what they want.

      I find that the term "Computer Engineering" is applied usually when you're dealing with the physical components of the computer much more than the software. Similarly "Software Engineering" is the process of designing the software itself. This is engineering just like construction work in the sense that you must create a structure that the code will fit into. "Computer programming" is the process where you take the structure and then fill in the code, once the design work has been done. Unfortunately the line between design and programming is usually very blurred (or nonexistant) and people spend far too little time on the design aspect, and then far too MUCH time on the programming because they don't know where they're going.

      By that very nature I find that people who say that there is no hard distinction between the "engineering" of the software and the "programming" of it usually don't know how to design very well (present company excluded of course).

      So from your final statement, yes, there is no analogy between "Construction Engineering" and "Programming" that is valid, however there are analogies between "Construction Engineering" and "Software Engineering" (design) that are quite valid.
  • by fm6 (162816) on Thursday November 15, 2001 @08:40PM (#2572376) Homepage Journal
    The analogy between engineering programs and engineering buildings is a reasonable one, and I've seen it used before. But there's an implication everybody seems to have overlooked.

    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 [uoguelph.ca] up [ketchum.org] occasionaly [icivilengineer.com]. You can argue that such failures are tragic, but are necessary for engineering to advance [amazon.com].

  • by Lostman (172654) on Thursday November 15, 2001 @08:41PM (#2572383)
    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?)
  • software stinking (Score:5, Informative)

    by egomaniac (105476) on Thursday November 15, 2001 @08:44PM (#2572397) Homepage
    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.

    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 ... 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.

    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.
    • by DaveAtFraud (460127) on Thursday November 15, 2001 @09:15PM (#2572517) Homepage Journal
      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.


      There is this company in Redmond, WA who seem to disprove this assertion on a regular basis.
    • When civil engineering was immature ... I doubt too many people stood around saying "You idiots!"

      Of course not, that wouldn't be civil :o)
    • 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?
      The other thing about that -- the design of bridges isn't holding back the production. The economics are incredibly different.

      If I had a "great" bridge idea, it wouldn't much matter, would it? Or a great building idea -- an Arcology or something. Skyscapers cost a billion dollars or so to produce, I believe. My great design simply isn't going to happen. And even the best building designs can't cut down the price that much -- no orders-of-magnitude advances to be made in one generation. There's just not nearly as much (relatively) at stake in the design of a building.

      But a good design for a program -- if you have a good design, you're golden. Hell, you're finished -- running your design (the program) through a compiler does not cost a billion dollars, even for the largest program.

      But maybe we should use the construction analogy, like you say: for a long time we've been building lots of mud huts. That was okay, because people need a place to live, even if it is humble. Too bad it melts in the rain.

      Now we've learned how to make wood houses, and behold, they are better. Some people are using even more advanced techniques -- brick and concrete, let's say -- and it can be cumbersome, because we haven't built the infrastructure to make those techniques that efficient yet -- it's sometimes hard to get good brick, just like you sometimes must program in C because the client likely won't have Java installed, and you can't build a second story on a mud hut no matter how good the design or materials.

      Some people use these more advanced techniques to build very good, very solid houses -- such things do exist, some software doesn't fail. Really. We have added more stories to our buildings, and built roads between them. Some people talk about skyscrapers, but everyone still needs a place to live, so most people make houses.

      And we're getting better -- the problems of yesteryear are not the problems of today. Our construction techniques have improved quickly, not on the timescale of epochs like construction. We should be damned proud. And software pushes the envelope more than construction does, but people seldom die when our software collapses, so what the hell.

    • well said.
      however, the design principles do exist now. When software is built with standard engineering proceess, it can work very well.
      Anybody who has designed firmware for a mission critical project knows that.
      Software quality CAN be better now, its just that managment can not see long term advantages. I probably should say that managment does not CARE about long term advantages. There usually not around long enough to care about saving time and money 3 years down the road.

      The market will have a hard time maturing because most software thats used by most people is not mission critical, and theres money in selling a new version. Its difficult to patch firmware, impossible most of the time.
      If a company built a bridge that fell down and still got paid year after year and was not liable for the results, how fast would bridge building have matured?
      would that same company pay the money needed for top notch engineers, or would they just hire a bunch of brick movers to stack bricks?
      we must demand quality from ourselves, from our managers, and form the companies that supply our software. If we don't we won't get it.

      and finally you said"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?!?"
      I would bet a dollar to donuts that people did say that(or the period equivalent).
      reminds me of a gary larson comic.
      Picture a guy i a 'Jetsons' like flying saucer zipping along with a cup of coffee on his roof.
      it has the caption:
      Technology changes, people don't.
  • It's well worth it. I think the current interest in quiet PCs is encouraging. Computers are plenty fast for most of us, so the next big push is going to be making them easier to live with. FireWire/USB, screwless cases, and "quiet" PCs are going to be increasingly popular in the future. I think that Apple's quiet and handy little Cube was a hint of things to come. Too bad they overcharged...

    Interestingly enough, the automobile industry followed a lot of the same trends. Horsepower and size were initially everything. There were always the economy models, but the real push was for bigger and faster cars. Now that even a Honda Civic has enough horsepower to get the job done, people are buying for different reasons. Style, comfort, and ease of use are BIG selling points for cars now, while horsepower is just another "nice feature" and the power enthusiast is relegated to a niche market.

    You can already see the trend at work. The Athlon is a kick-ass processor, but needing a monster heatsink and fans doesn't make them easy to live with. Ditto for the P4. The Crusoe is making inroads right now just for its' low heat output and the fact that it's "good enough". The main selling point for Seagate's Barracuda ATA IV is its' silence, despite the swarm of larger or faster drives (I bought one). Bulky/noisy/hot overclocker machines will always be there, but I'd look for mainstream PCs to get a LOT more friendly in the next couple years.

    • This isn't bull - its.. well, possible.

      Some scientists in the UK have tested rooms with high incidences of 'spooky occurences' for noise, magnetics and such. They find that InfraSound, low frequency sound, is very often present.

      They also found that this can resonate in your eyes. This makes you see grey patches - i.e. ghosts.

      Most fans wont create infra sound - but your CASE might!
    • If you're going to tantalize us with the claim that you own a totally silent PC, you are morally required to describe your system!
  • 200 years is a long time even for a Congressman.

    Yeah, 200 years is a long time. I wonder why Congress didn't take advantage of this when our country was just beginning about 200 years ago. If they had, imagine how much smarter we'd be today.

  • 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.
  • WTF is Star Trek X?

    Never heard of it. But I do admit, in Australia we're not exactly "in the loop" as far as new shit in America is concerned.

    A link or some other descriptive item would be nice.

    Thanks.
    • WTF is Star Trek X?

      It is an operating system made up of *nix and a really nice GUI. It really isn't out of beta yet and it will only run on on very expensive proprietary hardware. Depite all this there are six to eight rabid users.


    • WTF is Star Trek X?


      Haven't you noticed the US trend? Everything is X-something or Something eXtreme. Its marketing. And the Star Trek franchise has noticed.


      Of course - now that Star Trek: Enterprise has been launched, its time to get a few other Star Trek shows launched. Its worked before. So with the intent of going after an even younger, edgy audience there will be a new series to continue the trend established with ST:Enterprise.


      Star Trek eXtreme (aka Star Trek X).


      Or not.

  • bahamat wrote yesterday...

    So did someone else [wilwheaton.net] - scroll down...

    *sniff*
    2001-11-14 04:03:53 Wil Wheaton will be in Star Trek X (articles,movies) (rejected)

    Dang. It was worth a shot.

    Posted by wil @ 11/13/2001 08:17 PM PST


    So, who's the editor that saw a submission from CleverNickName in the queue regarding his cameo in STX and rejected it?

    Be sure to read the item linked above; LeVar Burton went to bat for Wil, and came through. Now, that's a friend.

  • I don't know much about the actual building of bridges but the Bridge Builder game [bridgebuilder-game.com] 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.
  • by joeflies (529536)
    that they named a Star Trek character after a Quake demo!
  • "...so it will be more worthwhile for a retail outlet to buy this and provide free unlocking services to their customers."
    Don't the retail outlets want to sell the higher clocked Athlons? Isn't that the idea behind the whole clock locking strategy? Anyway, kudos on coming up with the method, seems easier than the way TomsHardware did it.
  • Isn't Star Trek X supposed to be like, hundreds of years before the Wesley Crusher character? Oh well, just throw in another time-machine worm-hole.

One good reason why computers can do more work than people is that they never have to stop and answer the phone.

Working...