We have 10,000 test cases!
-
@dhromed said:
@Mason Wheeler said:
Don't make the mistake of confusing a bad idea with a bad implementation of a good idea.
This is generally spectacularly difficult to do.
I've seen it done far too frequently to believe that it's at all difficult to do, unless one is skilled at understanding good ideas. What I find spectacularly difficult to do, more often than not, is convince a non-programmer (and sometimes even fellow programmers) that a particular bad implementation does not say anything about whether the underlying idea was good.
At the end of a project to bring an identity management system online, most of my coworkers and just about everyone I talked to in management about it seemed to think that the issue was the concept of an identity management product. Only a handful of people (fortunately, this group includes my VP and our CIO) seem to understand that the issue was with a particular vendor's offering, as well as with the product selection process - which was to select the first product that we brought in for evaluation, because the director in charge of the project got antsy.
(Just in case anyone missed it above, that 'end' was the kind with stakes, garlic, and a bunch of nails, not the kind of finish where we had to maintain this lumbering, non-functional hulk for the rest of our days.)
-
@AndyCanfield said:
It's probably the 10/80/10 rule: 10% of programmers are very very good, 10% are very very bad, and 80% are mediocre. That should be independent of language, although market forces tend to select certain types.
Actually, it shouldn't be entirely independent of language. If a language is particularly unpleasant to work with for some reason, more competent programmers should avoid it. However, there are so many unpleasant languages out there, this effect is not as pronounced as some.
In the opposite direction, it's been noted that some languages which strive for simplicity get an unfair share of programmers who are not actually willing to learn programming. Since they're not willing to learn, they're perpetual neophytes, and just about always less competent than those who are willing to learn and have had several years to do so.
For example, BASIC. Err, sorry, I meant Visual BASIC for Applications.
Note that I'm not saying that there aren't some very competent VBA programmers out there. What I'm saying is it's more like 15/80/5 - or worse.
Also, if a language has aspects that make it particularly useful, it should have a slightly higher portion of competent programmers. However, I really haven't noticed this effect actually in play. (I'm discounting the LisP programmers I know who claim that LISP has this effect, because I feel that one of the hallmarks of good programming is that someone of moderate skill in the language should be able to read it, and these guys program in line noise.)
-
@tgape said:
@dhromed said:
@Mason Wheeler said:
Don't make the mistake of confusing a bad idea with a bad implementation of a good idea.
This is generally spectacularly difficult to do.
What I find spectacularly difficult to do, more often than not, is convince a non-programmer that a particular bad implementation does not say anything about whether the underlying idea was good.
That is exactly what I said.
-
@dhromed said:
@tgape said:
@dhromed said:
@Mason Wheeler said:
Don't make the mistake of confusing a bad idea with a bad implementation of a good idea.
This is generally spectacularly difficult to do.
What I find spectacularly difficult to do, more often than not, is convince a non-programmer that a particular bad implementation does not say anything about whether the underlying idea was good.
That is exactly what I said.
Ah. Sorry about that. I'm used to dealing with the gits around where I live who silently switch back to the positive when responding to a negative comment like that. Personally, it does seem like it should be fairly easy to tell the difference between a bad idea and a bad implementation of a good idea, and I'd guess that most of the regulars here (although there are some notable exceptions) would likewise make that distinction easily - including yourself. That also facilitated my misunderstanding of what you were saying. It's just sad that so few people seem inclined to spot flaws in implementations versus the base idea.
-
@dhromed said:
That is exactly what I said.
Is it?
From your quote, I read that making the mistake (not correcting it) was difficult to do.
Perhaps I'm misreading it, but others look to have made the same mistake.
-
@tgape said:
It's just sad that so few people seem inclined to spot flaws in implementations versus the base idea.
People tend to talk from three sources: opinion, fact and feeling.
The latter and former often cloud fact - emotions and perceptions can easily present a distorted view of reality, and an obvious danger is when emotion/perception is so strong that is becomes accepted as truth by others... biasing future decisions.
My general tactic is to challenge the strength of the sentence, to clarify if it will stand up to scrutiny, slowing down those that would otherwise impatiently pursue a folly. Doesn't always work, but just simple questioning often causes others to lose confidence in building a huge decision upon a vague whim.
-
@Cassidy said:
From your quote, I read that making the mistake (not correcting it) was difficult to do.
"Don't make the mistake"
"that is very hard to do"
-
@dhromed said:
FTFY@Cassidy said:
From your quote, I read that making the mistake (not correcting it) was difficult to do.
"Don't make the mistake"
"that is very hard to do"
-
@Sutherlands said:
@dhromed said:
FTFY@Cassidy said:
From your quote, I read that making the mistake (not correcting it) was difficult to do.
"Don't make the mistake"
"that is very hard to do"
Well now you've confused everybody.
I'll add to the pile and just say that it's not easy to make do.
-
@dhromed said:
@Sutherlands said:
@dhromed said:
FTFY@Cassidy said:
From your quote, I read that making the mistake (not correcting it) was difficult to do.
"Don't make the mistake"
"that is very hard to do"
Well now you've confused everybody.
I'll add to the pile and just say that it's not easy to make do.
But it's entirely too easy to make doo-doo.
