It's worth noting that multicore CPUs are just a plan B technology. What the market really wants is faster CPUs, but the current old technology can't deliver them, so CPU makers are trying to convince people that multicore is a good idea.
His interpretation of what I wrote is simply wrong. I didn't suggest any relationship between a programmer who is 10x more productive and a programmer who can write a 10x sort.
My point was that we should be as skeptical about unproven programmer productivity claims as we would be about other unproven claims. I just chose a sort routine as an arbitrary example of another kind of claim. I could have chosen something else and the point would have been the same.
Do you remember the HP-150 touchscreen PC that came out in 1983? It didn't sell that well. It turned out that people got tired lifting their hand up all the time.
I was just trying to get him to realize that he doesn't apply the same healthy skepticism to this productivity claim as he would to other claims. The choice of a sort as an example was completely arbitrary, I didn't establish any linkage between productivity and sorting.
Yes, and all the experts of the era said the Titanic was unsinkable. There's nothing wrong with designing for maintainability but you still have to measure the real-world outcome if you are serious about it.
First you say that if I "implemented some very complex system in less time then a competing group of 10 programmers did" you would "at least consider it possible" for me to create a 10x sort without proof.
Then you say: "That someone can do the same as a larger group and needs less time for it does in no way whatsoever compare to someone developing a 10x faster algorithm."
So if they're not comparable, why are you linking them?
"However, when when you know you can give a team of 5 engineers N days, or your good programmer N days, and get the feature delivered on time, that's a pretty good basis for comparison!"
Certainly there are cases where the nature of the problem doesn't lend itself well to a group effort, but that has nothing to do with a particular individual's productivity.
"You can engineer maintainability. You won't know how successful that effort was until after the maintenance is performed."
You can certainly try your best, but as you say, you only find out later how you did. But getting back to the main argument, programming "goodness" is a multidimensional quality that often can't be fully measured until some time has passed.
There is rarely any attempt to measure it in the real world beyond the misleading metric of LOC/time.
"I know what "productive" means. Knowing that is part of my job. "Productive" is delivering features in a maintainable, supportable way, per unit time. "
Maintainability can't really be determined during initial development, you have to wait until maintenance actually begins on a released product. Do you evaluate a project years later and trace its maintainability back to the individual programmer? If you do, you're certainly on the leading edge because I've never seen that done in my 20+ years of experience.
The flawed arguments just keep on coming. Is there nothing between 1x and 10x in your thinking? Of course some people are more skillful than others, but when you state numbers over 3X its starts to push common sense.
If I told you that I developed a new sorting method that is 10x faster than any known method, would you accept it on faith or expect some proof? Why should we get sloppy about these productivity claims?
"No, there really are programmers who are 10x as productive as "normal", and of course programmers who contribute negatively. You'll know either extreme when you work with one."
This is the most common programming myth of our time. We don't have any comprehensive definition of what "productive" means when applied to programming yet we know that some are 10x better at it. Or is it 30x? Or 100x? I've heard all of these figures claimed with no real proof.
Why when it comes to methodologies and productivity we drop out of objective programming mode and accept wild claims without proof simply because it gives us an ego boost. It's really a negative boost anyway - raising ourselves by pushing the other guys down.
Perhaps there is no "real talent" to use. Seriously, just because there are programmers out there who think they are better than most of the others, doesn't make it true.
Of course, if programmers who post on Slashdot were representative, we must all think we are über-programmers.
At least in America, if medical science can't figure out what causes a medical condition, they blame it on the patient's "bad" behavior.
For example, we were told for years that ulcers were caused by stress so the recommended treatment was to reduce stress. Then one day, oops, it was discovered that the most common cause was Helicobacter Pylori which can be treated with antibiotics.
"*shrug* I don't see how bootstraping the development of a free compiler with a non-free compiler is a violation of the mission to create a completely free computing system. "
In the wacky world where "freedom" applies to code, who knows. The point is that RMS makes his own arbitrary and extreme definitions of non-evil code.
"I really appreciate the position Stallman holds - that the sole reason he would ever use unfree software would be to write free software to replace it."
RMS could have avoided "unfree" software completely but apparently didn't have the assembly language chops to do it. So much for any hacker cred.
I don't see why anyone would think that RMS's arbitrary and inconsistent "philosophy" represents some great ethical value system.
"You know, I never thought I would comment on an idle story but this just pisses me off. I'm 6'5", does this mean that I'm entitled to always sit in the emergency exit row where there is more leg room, or 2 seats so I can stretch out?"
No, but feel free to wish your were obese and short if that seems more fair to you.
"Here's hoping the companies producing uncreative shrinkwrapped software go under."
But uncreative non-shrinkwrapped software is OK?
"Here's hoping the developers who refuse to learn more than basic typing skills go to other fields."
Some good developers don't even have basic typing skills. I don't care if developers who "refuse to learn" still get paid, although I've never met one in my 20+ years of experience.
"And here's hoping that intelligent, capable, and dedicated individuals can contribute to CS -- no matter where they were born."
I think you'll find that most in-house development is not open source. Try going to a randomly chosen business and ask them for a copy of their code and see what happens.
Closed source is not an anomaly but rather the business model that has driven software development from the beginning.
My experience is that in-house software is usually of much lower quality than shrink-wrapped products. In many companies if you mentioned alpha and beta testing to management they would think it had something to do with a supermarket.
"as a digital good that is virtually free to replicate, competition in "selling" software will lead to zero, regardless of whether it is FLOSS or closed, it all depends on marginal cost which is $0 for software (thanks bertrand [wikipedia.org])."
If we are going to assume that everybody will break laws, than all goods are free and all goods have no value.
Slashdot Mirror
It's worth noting that multicore CPUs are just a plan B technology. What the market really wants is faster CPUs, but the current old technology can't deliver them, so CPU makers are trying to convince people that multicore is a good idea.
His interpretation of what I wrote is simply wrong. I didn't suggest any relationship between a programmer who is 10x more productive and a programmer who can write a 10x sort.
My point was that we should be as skeptical about unproven programmer productivity claims as we would be about other unproven claims. I just chose a sort routine as an arbitrary example of another kind of claim. I could have chosen something else and the point would have been the same.
Is it really so hard to understand?
I don't understand what you mean by "see the link below.."
If you claim that I said something you should be quoting me, not somebody else.
Do you remember the HP-150 touchscreen PC that came out in 1983? It didn't sell that well. It turned out that people got tired lifting their hand up all the time.
No. He's contradicting himself.
I was just trying to get him to realize that he doesn't apply the same healthy skepticism to this productivity claim as he would to other claims. The choice of a sort as an example was completely arbitrary, I didn't establish any linkage between productivity and sorting.
Yes, and all the experts of the era said the Titanic was unsinkable. There's nothing wrong with designing for maintainability but you still have to measure the real-world outcome if you are serious about it.
First you say that if I "implemented some very complex system in less time then a competing group of 10 programmers did" you would "at least consider it possible" for me to create a 10x sort without proof.
Then you say: "That someone can do the same as a larger group and needs less time for it does in no way whatsoever compare to someone developing a 10x faster algorithm."
So if they're not comparable, why are you linking them?
"However, when when you know you can give a team of 5 engineers N days, or your good programmer N days, and get the feature delivered on time, that's a pretty good basis for comparison!"
What happened to the 10x? is it 5x now?
Certainly there are cases where the nature of the problem doesn't lend itself well to a group effort, but that has nothing to do with a particular individual's productivity.
"You can engineer maintainability. You won't know how successful that effort was until after the maintenance is performed."
You can certainly try your best, but as you say, you only find out later how you did. But getting back to the main argument, programming "goodness" is a multidimensional quality that often can't be fully measured until some time has passed.
There is rarely any attempt to measure it in the real world beyond the misleading metric of LOC/time.
"I know what "productive" means. Knowing that is part of my job. "Productive" is delivering features in a maintainable, supportable way, per unit time. "
Maintainability can't really be determined during initial development, you have to wait until maintenance actually begins on a released product. Do you evaluate a project years later and trace its maintainability back to the individual programmer? If you do, you're certainly on the leading edge because I've never seen that done in my 20+ years of experience.
The flawed arguments just keep on coming. Is there nothing between 1x and 10x in your thinking? Of course some people are more skillful than others, but when you state numbers over 3X its starts to push common sense.
If I told you that I developed a new sorting method that is 10x faster than any known method, would you accept it on faith or expect some proof? Why should we get sloppy about these productivity claims?
"No, there really are programmers who are 10x as productive as "normal", and of course programmers who contribute negatively. You'll know either extreme when you work with one."
This is the most common programming myth of our time. We don't have any comprehensive definition of what "productive" means when applied to programming yet we know that some are 10x better at it. Or is it 30x? Or 100x? I've heard all of these figures claimed with no real proof.
Why when it comes to methodologies and productivity we drop out of objective programming mode and accept wild claims without proof simply because it gives us an ego boost. It's really a negative boost anyway - raising ourselves by pushing the other guys down.
Perhaps there is no "real talent" to use. Seriously, just because there are programmers out there who think they are better than most of the others, doesn't make it true.
Of course, if programmers who post on Slashdot were representative, we must all think we are über-programmers.
"And this is rodent research, so there is no such thing as a double blind study."
Mister Peabody: "Surely, Neuronaut137, you've heard of the three blind mice."
At least in America, if medical science can't figure out what causes a medical condition, they blame it on the patient's "bad" behavior.
For example, we were told for years that ulcers were caused by stress so the recommended treatment was to reduce stress. Then one day, oops, it was discovered that the most common cause was Helicobacter Pylori which can be treated with antibiotics.
Sorry, I don't know what you're saying and I'm too lazy to look it up.
"*shrug* I don't see how bootstraping the development of a free compiler with a non-free compiler is a violation of the mission to create a completely free computing system. "
In the wacky world where "freedom" applies to code, who knows. The point is that RMS makes his own arbitrary and extreme definitions of non-evil code.
"I really appreciate the position Stallman holds - that the sole reason he would ever use unfree software would be to write free software to replace it."
RMS could have avoided "unfree" software completely but apparently didn't have the assembly language chops to do it. So much for any hacker cred.
I don't see why anyone would think that RMS's arbitrary and inconsistent "philosophy" represents some great ethical value system.
"You know, I never thought I would comment on an idle story but this just pisses me off. I'm 6'5", does this mean that I'm entitled to always sit in the emergency exit row where there is more leg room, or 2 seats so I can stretch out?"
No, but feel free to wish your were obese and short if that seems more fair to you.
"Here's hoping the companies producing uncreative shrinkwrapped software go under."
But uncreative non-shrinkwrapped software is OK?
"Here's hoping the developers who refuse to learn more than basic typing skills go to other fields."
Some good developers don't even have basic typing skills. I don't care if developers who "refuse to learn" still get paid, although I've never met one in my 20+ years of experience.
"And here's hoping that intelligent, capable, and dedicated individuals can contribute to CS -- no matter where they were born."
They have, for many, many, years.
I think you'll find that most in-house development is not open source. Try going to a randomly chosen business and ask them for a copy of their code and see what happens.
Closed source is not an anomaly but rather the business model that has driven software development from the beginning.
"Every year at appraisal time, the staff would be ranked in order of righteousness. The bottom 10% would be fired. No ifs, not buts, just fired."
So I guess Scott and Bill weren't considered part of the staff.
My experience is that in-house software is usually of much lower quality than shrink-wrapped products. In many companies if you mentioned alpha and beta testing to management they would think it had something to do with a supermarket.
"as a digital good that is virtually free to replicate, competition in "selling" software will lead to zero, regardless of whether it is FLOSS or closed, it all depends on marginal cost which is $0 for software (thanks bertrand [wikipedia.org])."
If we are going to assume that everybody will break laws, than all goods are free and all goods have no value.