Programming Quotes
-
Hi A capacitor. What I'm trying to say is that McConnell does have a point. If you dont change the way that you program a can program your self into a corner and no "bug fixing" will help out, one then would most likely have to re-write
Good architectural design, good implementation and good testing all create a quality product. If the first two are missing of course the last is useless. But even with average design and implementation good testing can raise the quality of a product to meet the markets requirements. And dont forget that it is not all about quality. Price and time to market are also important depending on the profile of the market one is targeting.
Truth is the subjection of reality to an individuals perception
-
Josh Smith wrote:
rock-dragging slaves being whipped in the hot sun
The key is to learn to love the whip.
Software Zen:
delete this;Gary R. Wheeler wrote:
The key is to learn to love the whip.
Or find a spear and huck it through the slavedriver's throat, as you run for freedom into the valley... :-D
:josh: My WPF Blog[^]
-
fat_boy wrote:
Oh for gods sake! Dont you think when I wrote 'find' that fixing them is also implied? Do you think anyone would leave a bug un-fixed once found?
No and Yes. The reality is that budget and schedule do not always allow all bugs that are found to be fixed, so some will inevitably not get fixed. On top of that, there are aften a number of bugs that don't get picked up with testing, but could have been avoided by writing the software a little bit smarter.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Here's one of mine, I think it was me that said it first, not sure though, I've used it a lot of times. "One day someone will look upon my code and say: 'What a hunk of junk, I wonder why it worked in the first place'. I recon there is a 90% chance that that person will be me." I usually say that when someone says my code is good.:P
MLeoDaalder wrote:
"One day someone will look upon my code and say: 'What a hunk of junk, I wonder why it worked in the first place'. I recon there is a 90% chance that that person will be me."
:rolleyes: excellent
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Dumbest. Movie. Title. Evaaar. The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Judah Himango wrote:
testing ... doesn't make your software better,
Wrong. (And I was a mechanical engineer before switching to software) any testing makes the product better. How the hell do you think Williams oe Ferrari win a Grand Prox? They didnt do that by rolling the car off the drawing board. They did it through good design, good implementation and good testing. And its the same for any engineered product or object. This is the problem with many programmers, they arent engineers. They dont know how to engineer something.
Truth is the subjection of reality to an individuals perception
fat_boy wrote:
I was a mechanical engineer before switching to software) any testing makes the product better.
So when you run a test and see that it breaks, it automatically makes the product better? Nope. It's not until you fix the problem, refactor and redesign better; only then your product is better. Testing just made you aware of the problem, and that was the original point all along.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Dumbest. Movie. Title. Evaaar. The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Judah Himango wrote:
testing ... doesn't make your software better,
Wrong. (And I was a mechanical engineer before switching to software) any testing makes the product better. How the hell do you think Williams oe Ferrari win a Grand Prox? They didnt do that by rolling the car off the drawing board. They did it through good design, good implementation and good testing. And its the same for any engineered product or object. This is the problem with many programmers, they arent engineers. They dont know how to engineer something.
Truth is the subjection of reality to an individuals perception
-
Judah Himango wrote:
testing ... doesn't make your software better,
Wrong. (And I was a mechanical engineer before switching to software) any testing makes the product better. How the hell do you think Williams oe Ferrari win a Grand Prox? They didnt do that by rolling the car off the drawing board. They did it through good design, good implementation and good testing. And its the same for any engineered product or object. This is the problem with many programmers, they arent engineers. They dont know how to engineer something.
Truth is the subjection of reality to an individuals perception
Isn't it better to think of testing as an integral part of the development process, and not separate from it? I think too many "developers" treat testing as a separate process to development when in fact testing *is* part of development! I prefer to code to a specification and then use testing to confirm the result. If a test fails then I cycle back to the code and repeat until all tests pass.... ...then I wait for the customer's user acceptance testing to tell me what I missed! :doh:
-
fat_boy wrote:
I was a mechanical engineer before switching to software) any testing makes the product better.
So when you run a test and see that it breaks, it automatically makes the product better? Nope. It's not until you fix the problem, refactor and redesign better; only then your product is better. Testing just made you aware of the problem, and that was the original point all along.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Dumbest. Movie. Title. Evaaar. The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
It's not until you fix the problem, refactor and redesign better; only then your product is better
No shit. What are you, such a pedant your head has dissapeared so far up your arse you cant see daylight? OF COURSE THE BUGS GET FIXED, THAT IS THE POINT OF TESTING!
Truth is the subjection of reality to an individuals perception
-
Would you hire someone who didn't bother to proofread their e-mails, but claimed to advocate quality improvement through testing? What would you hire that person to do?
-
Isn't it better to think of testing as an integral part of the development process, and not separate from it? I think too many "developers" treat testing as a separate process to development when in fact testing *is* part of development! I prefer to code to a specification and then use testing to confirm the result. If a test fails then I cycle back to the code and repeat until all tests pass.... ...then I wait for the customer's user acceptance testing to tell me what I missed! :doh:
-
OK, heres the spec: 1) It has to work. So how do you fold that into a classic spec-design-test scenario. You cant.
Truth is the subjection of reality to an individuals perception
Ah yes, “make it work.” Many years ago I attended a programming enrichment class sponsored by my employer. The guy that gave the class was a “it all about the specs” kind of guy. I joked and suggested that if the spec was that rigorous that one could develop a spec compiler and dispense with software jobs completely. He said that a spec compiler existed and offered to take my card and send me something about it. I never got it. Even when I had an interface spec I managed to get opcodes changed to a series of bits – one bit for each action I was to perform. Thus I had one bit for write another for read, another for multi-record format and another one or two that I forget. It saved the day because due to the excessive compute overhead of VM360 with I/O we had to add a multi-track bit. And the thing worked for every opcode bit pattern. Precognition or luck? It sure wasn’t the spec. Somebody hire me. Check out http://hmtown.com
-
Ah yes, “make it work.” Many years ago I attended a programming enrichment class sponsored by my employer. The guy that gave the class was a “it all about the specs” kind of guy. I joked and suggested that if the spec was that rigorous that one could develop a spec compiler and dispense with software jobs completely. He said that a spec compiler existed and offered to take my card and send me something about it. I never got it. Even when I had an interface spec I managed to get opcodes changed to a series of bits – one bit for each action I was to perform. Thus I had one bit for write another for read, another for multi-record format and another one or two that I forget. It saved the day because due to the excessive compute overhead of VM360 with I/O we had to add a multi-track bit. And the thing worked for every opcode bit pattern. Precognition or luck? It sure wasn’t the spec. Somebody hire me. Check out http://hmtown.com
Yep, I do device drivers. They have one spec. It has to work. For ever, without BSODing the PC. That means not one single exception, not one single fault, ever. The code has to be perfect. And you only get that by testing it to destruction, untill every line of code has been run in every situation the user is ever going to find himself in. And the fools on this forum tell me testing doesnt make a better product!
Truth is the subjection of reality to an individuals perception