Slashback: Crusher, Satellites, Silence 241
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.
COOOOOOOL (Score:1)
But quite a few years have past... I hope the SF people can make Wil look young again
Cameo as Will Crusher? (Score:2, Interesting)
Re:Cameo as Will Crusher? (Score:2)
cameo: noun - a small theatrical role usually performed by a well-known actor and often limited to a single scene; broadly : any brief appearance
Re: (Score:1)
Wil Wheaton on The Tick - with sweater? (Score:2)
I mean, think about the banter between Wesley Crusher and the Blue Icon of Justice!
-
Re:Wil Wheaton on The Tick - with sweater? (Score:1)
Re:Wil Wheaton on The Tick - with sweater? (Score:1)
Yeah, that would actually be the best Wesley Crusher role.
Although I'm sure some of us would love to see Wil do Sewer Urchin
-
What in God's name... (Score:2, Informative)
Re:What in God's name... (Score:1)
Re:What in God's name... (Score:2)
ncc74656:
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]
Re:What in God's name... (Score:2, Insightful)
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."
Re:What in God's name... (Score:2)
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]?
Re:What in God's name... (Score:2)
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.
Re:What in God's name... (Score:2)
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 !!
Re:What in God's name... (Score:1)
Which web browser is that? Specifically, I want to know the one that runs under MINIX.
Thanks.
Re:What in God's name... (Score:1, Troll)
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.)
Re:What in God's name... (Score:3)
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.
Re:What in God's name... (Score:2)
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.
Silence is Golden... (Score:4, Funny)
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!
Kids, don't try this at home! (Score:1)
(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)
Wesley's dead, dude.
Commented code (Score:5, Insightful)
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)
Re:Commented code (Score:2)
Re:Commented code (Score:3, Insightful)
The only way to explain any of this is with comments. If anyone gives me a piece of code to review with a complex bit of maths in it, and it doesn't explain why it does it the way it does, any optimisation, scaling factors or what happens in the event of overflow/underflow (if appropriate), then I will send it back to the coder with a review comment saying to add any or all of these as required.
Code doesn't get stale, it gets forgotten. Several years later, you will not remember how it works - that's a fact of professional life. If you've used some really neat hack, the only way you'll remind yourself what you did back then is to add comments, and it's certainly the only way for anyone else to work it out.
The issue is with ppl thinking that code and comments are separate and can be updated individually. It's not an "either-or" - a coder must produce well-designed code with properly-thought-out names andvalid comments. If they don't, they're either bad coders or inexperienced coders, and at review they should be shown how to improve the quality of their code. Stale comments must not be allowed through review - this is just one example of problems in bad code. If your code is not subject to review, you are not working in an professional software environment. If you are working in a professional software environment and your code and design are not reviewed, then you and your company are practising gross negligence and the lawsuit from a customer is just waiting to happen!
I agree that 3:1 is BS - the actual amount of comments required depends on the code you're writing. I've written a matrix library where there's about a 5:1 ratio of comments to code; I've also written analogue input device drivers with simple range-checks and filtering with a ratio of less than 1:1.
Grab.
Re:Commented code (Score:2)
Re:Commented code (Score:2)
Also, it's silly to eschew all comments because some comments are inaccurate. A comment that don't match the code should be considered a bug like any other. Inaccurate comments should be fixed, even if only by adding "TODO: double-check this comment--it seems wrong".
Re:Commented code (Score:2)
Java is pretty much self-documenting, but that's because it's not much more than library calls and the names of everything in the standard library are 30 characters long, practically.
Have you never had to maintain someone else's code?
Re:Commented code (Score:1)
Re:Commented code (Score:2)
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?
Re:Commented code (Score:2)
Isn't there something like overdoing it? (Score:3, Informative)
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.
Re:Isn't there something like overdoing it? (Score:2)
Literate code (Score:2)
:)
hawk
Re:Commented code (Score:3)
Re:Commented code (Score:1)
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.
Re:Commented code (Score:2)
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)
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?).
Wesley Crusher is a gracious net.celebrity (Score:2)
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.
Re:Wesley Crusher is a gracious net.celebrity (Score:1)
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.
-
Re:Wesley Crusher is a gracious net.celebrity (Score:2)
You've done a great job dealing with a tough situation, Will. Kudos.
Last chance for a Pluto mission for 200 years? (Score:3, Informative)
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?
Kindlers unite! (Score:1)
Re:Kindlers unite! (Score:2)
Why the Contruction Analogy sucks: (Score:5, Insightful)
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.
Software Engineering is not Programming (Score:3, Insightful)
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.
I can speak only from experience (Score:4, Insightful)
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.
Engineer versus Engineering (Score:2)
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.
Re:I can speak only from experience (Score:2)
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.
I think you may need more experience.... (Score:2, Insightful)
> 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'.
Software and engineering (Score:1)
Re:Why the Contruction Analogy sucks: (Score:2, Interesting)
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).
Re:Why the Contruction Analogy sucks: (Score:2)
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.
Re:Why the Contruction Analogy sucks: (Score:1)
Re:Why the Contruction Analogy sucks: (Score:2)
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.
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. Both software and structures can be thrown together with little engineering work, but that doesn't make them good. They are. Take a look at the engineering documentation for a skyscraper, car factory, or refinery sometime.Re:Why the Contruction Analogy sucks: (Score:2)
Re:Why the Contruction Analogy sucks: (Score:2)
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?
Wrong. (Score:2)
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.
Re:Why the Contruction Analogy sucks: (Score:2)
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.
Re:Invert the analogy (Score:2)
You mean, unles they were Open Source programs?
Of course it sucks.... (Score:3, Insightful)
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].
A stupid question, I'm sure, but. . . (Score:3, Interesting)
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?)
Re:A stupid question, I'm sure, but. . . (Score:5, Informative)
Re:A stupid question, I'm sure, but. . . (Score:1)
The Pencil Trick (Score:5, Funny)
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.
Hardware of the Beast (Score:2)
software stinking (Score:5, Informative)
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.
Re:software stinking (Score:4, Insightful)
There is this company in Redmond, WA who seem to disprove this assertion on a regular basis.
Re:software stinking (Score:2)
I wasn't speaking of stuff thrown together by "rabid marketing departments".
Re:software stinking (Score:2, Funny)
Of course not, that wouldn't be civil
Re:software stinking (Score:2)
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.
Re:software stinking (Score:2)
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.
From someone who owns a totally silent PC... (Score:2, Interesting)
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.
NOISE MAKES YOU SEE GHOSTS (Score:2)
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!
I want yours (Score:2)
"Silent" Seagate and Fanless systems (Score:2)
Still, 24 decibels is pretty low. I've heard 40 quoted as an acceptable background noise for a sound studio, though most sources say 10. Assuming Seagate measured intensity right next to the drive, little or no sound must escape from the case.
I looked at marketing blurbs for various recent drives. All the products that are supposed to be "quiet" list seeking noise somewhere below 40 decibels. (Of course, all use bels instead of decibels, and none given sound frequency or the distance at which the sound intensity was measured.) I'm no acoustic engineer, but I rather suspect that any of these drives could be made "silent" with the right enclosure.
The fan is certainly going to be a much bigger noise source. It's a pity nobody tries to make fanless systems unless Steve Jobs is looking over their shoulder!
I'm a little bemused to hear a 450 Mhz G4 system described as "starting to show its age". What kind of app is it too slow to run? And are you sure the processor is the bottleneck? I'm not a Mac enthusiast, but the number-crunching superiority of the G4 architecture is pretty blatant. Perhaps an video card upgrade is in order.
They should have done this last time. (Score:1, Troll)
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.
200 years is a long time? (Score:2)
Re:200 years is a long time? (Score:2)
Worked as Civil and Software engineer (Score:2, Informative)
okay... (Score:2)
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.
Re:okay... (Score:2)
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.
Re:okay... (Score:2)
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.
First-hand sources (Score:1)
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.
Software Engineering vs Bridge Building (Score:2, Informative)
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.
That's so cool (Score:2, Funny)
overclocking (Score:2)
umm... (Score:2)
Re:Wil Wheaton is a bit of a sexist oaf. (Score:4, Informative)
Allow me to point you to Wil's previous comment on the interview [slashdot.org].
Summary: he was joking.
Re:Wil Wheaton is a bit of a sexist oaf. (Score:2)
A little research goes a long way, Anton.
Re:Wil Wheaton is a bit of a sexist oaf. (Score:1)
Re:Star Trek X (Score:1)
Anyway sarcasm aside, while rumor does have a lot of power, I would take anything you hear with a grain of salt.
Re:Star Trek X (Score:1)
Depending on how successful Spiner is in his negotiations, maybe the the movie will open with Data's severed head on a table.
Re:Star Trek X (Score:3, Funny)
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. [startrek.com]
It didn't work. [startrek.com]
:-P
Re:Star Trek X (Score:3, Funny)
Re:Star Trek X (Score:2)
ttyl
Farrell
Re:Star Trek X (Score:4, Funny)
I take it that you haven't installed XP yet.
Re:Star Trek X (Score:1)
Re:Its sad that I can argue this but... (Score:2)
I admit it, your knowledge of Star Trek, The Next Generation far exceeds my own. I only vaguely remembered the episode at all, and that he had smashed up the glass thing. By the way, there are many vague laws even in our country. Let's say there's a street where the speed limit isn't posted, so you go the speed you assume the street should be, right? Well, then you get pulled over by a cop who tells you that you should have been going slower. "But it wasn't posted!" And then the cop says, "Ignorance from the law is no excuse." Even if you're from another state and had no idea that this street had a weird speed limit. Yeah, that's right. "Ignorance from the law is not an excuse" is a bureaucrat's excuse for being a jack ass.
As far as there being girls and "some games," I think I'll need to watch that episode again. If they're cute, then Crusher really was an idiot.
Oh yeah, I thought I might add this: The word "idiot" is not the language of a 2nd grader. It's the language of someone from Indiana, where it's pronounced the correct way: "idjit."
Re:"That fetid odor continues to rise" (Score:2)
bright light: a light that is full of light or illumination.
See my point?