Programming Quotes
-
You almost sound like my previous boss. He wanted to fix everything with a cap. If there was noise on the line he want to use a cap, if software was not performing because of "noise" then I must use a cap.:laugh: Just does not make sense does it? Well having seen the way some cowboys program I'm amazed that the IT industry is still on it's feet. The sory of change diet works for me :) Regards
BLOEDHOND wrote:
He wanted to fix everything with a cap
What is CAP?
BLOEDHOND wrote:
Well having seen the way some cowboys program I'm amazed that the IT industry is still on it's feet
Are you calling me a cowboy? If you are then you are a fool. I was in mech eng before SW. Now I am doing device drivers for windows. If you dont test, youve got unfound bugs. IF youve ghot bugs you dont sell product, and that is one reason the company I work for has 82% of market share in europe and 32% globally. Dont tell me testing doesnt improve quality. Thats a load of intellectual crap.
Truth is the subjection of reality to an individuals perception
-
BLOEDHOND wrote:
He wanted to fix everything with a cap
What is CAP?
BLOEDHOND wrote:
Well having seen the way some cowboys program I'm amazed that the IT industry is still on it's feet
Are you calling me a cowboy? If you are then you are a fool. I was in mech eng before SW. Now I am doing device drivers for windows. If you dont test, youve got unfound bugs. IF youve ghot bugs you dont sell product, and that is one reason the company I work for has 82% of market share in europe and 32% globally. Dont tell me testing doesnt improve quality. Thats a load of intellectual crap.
Truth is the subjection of reality to an individuals perception
-
Programming Quotes Page[^] :cool: My favorite:
Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don't improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don't buy a new scale; change your diet. If you want to improve your software, don't test more; develop better. Steve McConnell Code Complete
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
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
-
Ryan Binns wrote:
No. When you fix the bugs you have a better quality product
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?
Truth is the subjection of reality to an individuals perception
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"
-
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"
-
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
-
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
-
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