Hundreds of books and resources have been written/made available on the subject. You won't find the "right" answer for "you" here. No one here knows your environment/situation/funding/etc. I suggest following the leads the folks here are pointing you to and go from there.
Word of wisdom; don't assume automated testing is the best choice for everything.
7 minutes to 28 seconds? I don't doubt the numbers he saw but I wonder if he was comparing apples to apples or not. There are tons of things that could have given him false (or inaccurate) data like fragmentation differences, bios settings (think DMA), where on the drive the data was located, and on and on.
I agree with another poster who suggested using a real benchmark utility. People see what they want to see. He saw 7 minutes to 28 seconds. I haven't decided what I'm seeing yet...
Who the heck ever thought this was a good idea? (as described in the links).
I wish the computer industry would focus more on usability than on "bells and whistles" that produce a bunch of "Oohs" and "Ahhs" and make programmers feel cool.
Of course, I do appreciate innovation and maybe this could lead to something more useful than it's current implementation/use.
This one should be rated up to +5 Funny. It's more sarcastic than most of you seem to realize.
Adding version control for "the rest of the company figures" to use is a BAD idea if you plan on using version control systems that were designed for source code.
Just because you have a verion control system that your company uses doesn't mean that the people will use it properly.
Trust me!!!!!!!!!!! Without PROPER training with version control systems you'll end up with more hassle than you bargained for.
I would NOT recommend a source code version control system for this persons needs. He's not asking for one anyway.
The best idea I've read so far was from someone suggesting that a single person manage a directory or documents and does not allow others write access. When something needs to be updated this person manages all of that. Full time job unfortunately.
Ok, I've made no sense now and have been unable to communicate my point. I give up, maybe someone can help.
Overall, an interesting read. I have a few comments to make though...
Tests cover everything that could possibly break
Absolutely impossible in todays world, unless you're writing a "hello world" application in an ancient operating system (DOS) with no multithreading or distributed components.
When a bug appears, the programmer writes tests to demonstrate it.
Good,
After fixing the bug in the code, he runs all tests again. This not only proves that the fix corrects the defect, but it proves that the correction did not break any other features.
Not good. Although the statement made is simple and seemingly true, it holds less and less value as developer count and software complexity increase. It would take an expert in the software to *Truly* understand what impact a code change *might* have on the rest of the product. A developer in todays world rarely has a *full* knowledge of the product he/she is working on and cannot form a valid judgement as to the overall impact, (although for the most part they usually are very intelligent...).
Make it easy for users to report failures.
I agree.
After writing a test, write the simplest possible code that could pass it...................Good tests free you to change things in the future by identifying the effects of a change. Simple code localizes changes, reducing interconnections. Besides that, your design will change. Adding a feature will take the same amount of time whether you do it now or in the future.
I totally 100% disagree with this statement. It is ALWAYS more costly to implement change or new functionality later in the software life cycle. Possibly, at best, it may help reduce time in the long run but it definitely will not take the same amount of time.
Slashdot Mirror
No, it won't eliminate broken links....It'll simply redefine what a broken link is.
As far as I'm concerned if it's not the originally intended link it may as well be "broken".
Hundreds of books and resources have been written/made available on the subject. You won't find the "right" answer for "you" here. No one here knows your environment/situation/funding/etc. I suggest following the leads the folks here are pointing you to and go from there.
Word of wisdom; don't assume automated testing is the best choice for everything.
7 minutes to 28 seconds? I don't doubt the numbers he saw but I wonder if he was comparing apples to apples or not. There are tons of things that could have given him false (or inaccurate) data like fragmentation differences, bios settings (think DMA), where on the drive the data was located, and on and on.
I agree with another poster who suggested using a real benchmark utility. People see what they want to see. He saw 7 minutes to 28 seconds. I haven't decided what I'm seeing yet...
Who the heck ever thought this was a good idea? (as described in the links).
I wish the computer industry would focus more on usability than on "bells and whistles" that produce a bunch of "Oohs" and "Ahhs" and make programmers feel cool.
Of course, I do appreciate innovation and maybe this could lead to something more useful than it's current implementation/use.
Do we really need Slashdot to tell us this?
This one should be rated up to +5 Funny. It's more sarcastic than most of you seem to realize. Adding version control for "the rest of the company figures" to use is a BAD idea if you plan on using version control systems that were designed for source code. Just because you have a verion control system that your company uses doesn't mean that the people will use it properly. Trust me!!!!!!!!!!! Without PROPER training with version control systems you'll end up with more hassle than you bargained for. I would NOT recommend a source code version control system for this persons needs. He's not asking for one anyway. The best idea I've read so far was from someone suggesting that a single person manage a directory or documents and does not allow others write access. When something needs to be updated this person manages all of that. Full time job unfortunately. Ok, I've made no sense now and have been unable to communicate my point. I give up, maybe someone can help.
Computers are only a tool
I think the question can really only be answered to applying it to a particular task.
There are almost always good solutions to a certain task that can be considered good.
Next thing that must be done is to define "Good Code". I'm sure everyone has their own opinion as to what good code is;
Readable, Well Commented, Efficient Algorithm, Proper Naming Conventions, Follows Appropriate Documented methods, etc...etc...
I'm sure there are hundreds others!
Perhaps a question like "What defines good code" would still be only slightly more beneficial to those reading the posts.
Overall, an interesting read. I have a few comments to make though...
.......... .........Good tests free you to change things in the future by identifying the effects of a change. Simple code localizes changes, reducing interconnections. Besides that, your design will change. Adding a feature will take the same amount of time whether you do it now or in the future.
Tests cover everything that could possibly break
Absolutely impossible in todays world, unless you're writing a "hello world" application in an ancient operating system (DOS) with no multithreading or distributed components.
When a bug appears, the programmer writes tests to demonstrate it.
Good,
After fixing the bug in the code, he runs all tests again. This not only proves that the fix corrects the defect, but it proves that the correction did not break any other features.
Not good. Although the statement made is simple and seemingly true, it holds less and less value as developer count and software complexity increase. It would take an expert in the software to *Truly* understand what impact a code change *might* have on the rest of the product. A developer in todays world rarely has a *full* knowledge of the product he/she is working on and cannot form a valid judgement as to the overall impact, (although for the most part they usually are very intelligent...).
Make it easy for users to report failures.
I agree.
After writing a test, write the simplest possible code that could pass it
I totally 100% disagree with this statement. It is ALWAYS more costly to implement change or new functionality later in the software life cycle. Possibly, at best, it may help reduce time in the long run but it definitely will not take the same amount of time.
This one received a lot of laughs at work this morning. Keep it coming!
A good way to start my day.
Anyone else seen any "Comical" Y2K readiness posts
like this one?