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.
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.
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.
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].
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.
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:software stinking (Score:4, Insightful)
There is this company in Redmond, WA who seem to disprove this assertion on a regular basis.
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.
Re:okay... (Score:1, Insightful)
i) you read
ii) you use the web
What frikken "loop" are you looking to be in, in particular???
From one Ozzie to another, I got three words (in true Ozzie style that you will grasp quite easily)...
SEARCH ENGINE DICKHEAD!!!!
WTF! indeed.... Aussies out of the loop.... pffffftttt!!!.... Please don't generalise all Australians as incompetent, or ill informed for that matter. Your lack of initaitive is an issue that is yours alone.
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'.
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:1, Insightful)
This is the same guy who made it company policy to put a lengthy comment before every subroutine we write, documenting every single thing it does, and then writes crappy documentation.
I will say that there are times when a 3:1 comment:code ratio is called for. But mind the above, and Be Careful What You Wish For.