(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Tuesday, April 01, 2008
Raganwald in disagreement
Relax, this is not one of the 17,322 April Fool’s posts to arrive in your feed reader today. Quite seriously, I just discovered that I am inconsistent, and that is very interesting in a Raymond Smullyan
kind of way.
Here’s the thing: Many of my posts extol the virtues of programmers to producing programs. Not everyone agrees, of course, many people claim what you need are these “engineering principles” and even complete idiots will magically produce working software with terrific ROI over the complete software lifetime. Naturally, when these principles are elucidated, they are quickly diminished, because if you can name one such principle, you can also find someone who tried it and failed.
Of course, the same goes for smart people: it’s easy to hand wave and say, “You need smart people who can get things done.” But that’s begging the question: looking at a successful project and declaring that the people were smart and did get things done is easy. But coming up with an unambiguous and objective measure for deciding who is smart and who will get things done is hard.
Any blogger can rant (as I rant) about smart people, but the easy reply is to ask for a repeatable process for selecting such people. What’s on their résumé? What questions do you ask in the interview? How many references do you check? What do you look for in their portfolio? What do you expect to see in their code samples?
Not so easy, is it?
Any ways, let’s accept that I rant about programmers being important without having any sort of objective, reproducible process for selecting such programmers. A scientist would laugh at me, but then again a scientist would laugh at everyone mumbling about software project management and the ROI from using Java instead of Lisp—such claims are equally unproven.
However, let’s be charitable and chalk it up to optimism. Fine.
But what’s with my posts extolling the virtues of programming languages and suggesting they are important? If a better language (whatever that means) can make a good programmer better, why can’t it make a mediocre programmer acceptably average?
And if good programmers are “All that and a fresh bag of chips,” why can’t they do just fine with Java or Visual Basic? Why do they need these so-called better languages?
Well? What’s the deal? Is it the programmer? Or is it the tool?
Relax, this is not one of the 17,322 April Fool’s posts to arrive in your feed reader today. Quite seriously, I just discovered that I am inconsistent, and that is very interesting in a Raymond Smullyan
kind of way.Here’s the thing: Many of my posts extol the virtues of programmers to producing programs. Not everyone agrees, of course, many people claim what you need are these “engineering principles” and even complete idiots will magically produce working software with terrific ROI over the complete software lifetime. Naturally, when these principles are elucidated, they are quickly diminished, because if you can name one such principle, you can also find someone who tried it and failed.
Of course, the same goes for smart people: it’s easy to hand wave and say, “You need smart people who can get things done.” But that’s begging the question: looking at a successful project and declaring that the people were smart and did get things done is easy. But coming up with an unambiguous and objective measure for deciding who is smart and who will get things done is hard.
Any blogger can rant (as I rant) about smart people, but the easy reply is to ask for a repeatable process for selecting such people. What’s on their résumé? What questions do you ask in the interview? How many references do you check? What do you look for in their portfolio? What do you expect to see in their code samples?
Not so easy, is it?
Any ways, let’s accept that I rant about programmers being important without having any sort of objective, reproducible process for selecting such programmers. A scientist would laugh at me, but then again a scientist would laugh at everyone mumbling about software project management and the ROI from using Java instead of Lisp—such claims are equally unproven.
However, let’s be charitable and chalk it up to optimism. Fine.
But what’s with my posts extolling the virtues of programming languages and suggesting they are important? If a better language (whatever that means) can make a good programmer better, why can’t it make a mediocre programmer acceptably average?
And if good programmers are “All that and a fresh bag of chips,” why can’t they do just fine with Java or Visual Basic? Why do they need these so-called better languages?
Well? What’s the deal? Is it the programmer? Or is it the tool?
Comments on “Raganwald in disagreement”:
<< Home
This is a response to How to Disagree, of course. I wanted to give an example of another kind of debating device, pointing out when someone contradicts themself.
It is not necessarily a terrific approach. It can lower itself to the point of lawyers arguing that their clients should be acquitted on a technicality, or it can be a very important way to show that an idea is fundamentally unsound because the idea contradicts itself.
In this case, I am really not using contradiction in that important sense: I am not showing that valuing good programmers is itself a contradictory idea, rather I am showing that my blog contradicts itself.
This might be valuable if arguing whether my blog is—as a whole—a consistent system for reasoning about software development. But it has no bearing on whether hiring good programmers is a good idea, and if we were arguing that point this would be more of an ad hominem: “How can you believe him, he was arguing for better languages just the other day!”
Such an ad hominem, while emotionally provocative, is irrelevant, because if an idea is flawed it can be refuted on its own lack of merit.
It is not necessarily a terrific approach. It can lower itself to the point of lawyers arguing that their clients should be acquitted on a technicality, or it can be a very important way to show that an idea is fundamentally unsound because the idea contradicts itself.
In this case, I am really not using contradiction in that important sense: I am not showing that valuing good programmers is itself a contradictory idea, rather I am showing that my blog contradicts itself.
This might be valuable if arguing whether my blog is—as a whole—a consistent system for reasoning about software development. But it has no bearing on whether hiring good programmers is a good idea, and if we were arguing that point this would be more of an ad hominem: “How can you believe him, he was arguing for better languages just the other day!”
Such an ad hominem, while emotionally provocative, is irrelevant, because if an idea is flawed it can be refuted on its own lack of merit.
Having good programmers seems to correlate with good results. Using good tools also seems to correlate with good results. And good programmers tend to use good tools, as well. Separating out the causation from all the correlation isn't trivial.
(Though perhaps DeMarco and Lister have enough data for a clever researcher to start the process?)
(Though perhaps DeMarco and Lister have enough data for a clever researcher to start the process?)
Jay:
Very true, although if we can show that A and B are correlated with success, but we cannot show a direct causal relationship, we should take this as a sign that we need to continue to search for understanding.
I do not think we really understand how to develop software yet.
Very true, although if we can show that A and B are correlated with success, but we cannot show a direct causal relationship, we should take this as a sign that we need to continue to search for understanding.
I do not think we really understand how to develop software yet.
One of the reasons good programmers are "All that and a fresh bag of chips" is because they don't put up with people, tools, processes or anything else that gets in the way of them delivering the right software. So I don't think the considerations separate as easily as you seem to be implying.
"Well? What’s the deal? Is it the programmer? Or is it the tool?" You're right. It's gotta be the shoes.
Also, you have to remember team issues. One programmer may be just as good as another in isolation, but their personalities might prevent them from successfully cooperating on anything.
If you maximize "goodness" along all the possible degrees of freedom, you'll probably get better results than someone working to improve only a single dimension.
If you maximize "goodness" along all the possible degrees of freedom, you'll probably get better results than someone working to improve only a single dimension.
The fallacy here is that it's reasonable to expect you'll have access to great programmers.
Unlike Lake Wobegon, half of us are below-average. And odds are, unless you're doing really spectacular stuff at a company that really knows its shit, then you are probably working with a good percentage of average (if not below-average) developers.
So the real question is -- what tools and techniques are optimal for the slightly-below-average to slightly-above-average developers? (You know, the big, fat middle of that bell curve.)
Unlike Lake Wobegon, half of us are below-average. And odds are, unless you're doing really spectacular stuff at a company that really knows its shit, then you are probably working with a good percentage of average (if not below-average) developers.
So the real question is -- what tools and techniques are optimal for the slightly-below-average to slightly-above-average developers? (You know, the big, fat middle of that bell curve.)
Joe:
And your argument presupposes 1. that there is an efficient market, and 2. all participants have the same strategy for maximizing their utility.
At this moment in time, I do not believe that we are very good at identifying good people, so even if everybody tries to do it, you might be a little bit better at it than others and therefore will hire more of them.
And my second point is that I laugh like this:
mwahahahaha!
...When considering whether everybody is trying to hire good people. They are most decidedly not.
Quite frankly, if you decide that hiring good people is your key strategy, and then organize your offices, your reporting and management hierarchy, your selection of tools, and everything else around that strategy, you will be in a very small minority.
So...
Half the people may be below the median, and therefore some large number of employers may be unable to hire good people, however in this inefficient marketplace featuring players pursuing heterogeneous and mixed strategies, it is possible to pursue good people and have some expectation of hiring them.
And your argument presupposes 1. that there is an efficient market, and 2. all participants have the same strategy for maximizing their utility.
At this moment in time, I do not believe that we are very good at identifying good people, so even if everybody tries to do it, you might be a little bit better at it than others and therefore will hire more of them.
And my second point is that I laugh like this:
mwahahahaha!
...When considering whether everybody is trying to hire good people. They are most decidedly not.
Quite frankly, if you decide that hiring good people is your key strategy, and then organize your offices, your reporting and management hierarchy, your selection of tools, and everything else around that strategy, you will be in a very small minority.
So...
Half the people may be below the median, and therefore some large number of employers may be unable to hire good people, however in this inefficient marketplace featuring players pursuing heterogeneous and mixed strategies, it is possible to pursue good people and have some expectation of hiring them.
I feel that I'm under the average, should I consider suicide ?
More seriously, Mc Cartysm is dead a long time ago, moreover, this blame game is futile.
the reason the project fail are :
- people (bad developers stuff)
- system (Fifth disciplmine stuff)
- it was not the good market
- we did not give the market what it needed
- the tools where no fit for the job
- we ran out of money before getting to the goal
And I have a good new : when you're seated before a wreck professing your diagnostic for the failure, nobody can contradict you with better arguments than yours, there is no formal proof for such an argument. This is the good time to profess your belief, reinforce them, and enter in a debate that will not change tyour state of mind. During this time, productive people will try to do something else.
I hate this "good developer" stuff, I don't feel I'm good and I refuse to admit that my future is cleaning the toilet. And if you feel people can get better with time, why struggle to hire the best ? you can teach them. This policy of blaming the worst developers and trying to recruit the best ones embeds in itself the belief that people don't change.
More seriously, Mc Cartysm is dead a long time ago, moreover, this blame game is futile.
the reason the project fail are :
- people (bad developers stuff)
- system (Fifth disciplmine stuff)
- it was not the good market
- we did not give the market what it needed
- the tools where no fit for the job
- we ran out of money before getting to the goal
And I have a good new : when you're seated before a wreck professing your diagnostic for the failure, nobody can contradict you with better arguments than yours, there is no formal proof for such an argument. This is the good time to profess your belief, reinforce them, and enter in a debate that will not change tyour state of mind. During this time, productive people will try to do something else.
I hate this "good developer" stuff, I don't feel I'm good and I refuse to admit that my future is cleaning the toilet. And if you feel people can get better with time, why struggle to hire the best ? you can teach them. This policy of blaming the worst developers and trying to recruit the best ones embeds in itself the belief that people don't change.
It's rarely ever one OR the other. However, most people (myself included) have a strong desire for this to be true. Most disagreement is due to arguing about which one it is, when it's not clearly either.
"I hate this good developer stuff... This policy of blaming the worst developers and trying to recruit the best ones embeds in itself the belief that people don't change."
Well, you have taken huge liberties with what I have written here. You are, to put it mildly, arguing with yourself.
If you believe that people can be taught, if you believe that "people can get better with time," then YOU believe that some are better than others for a particular task on a particular day.
The alternative belief is that all developers are exactly equal to each other and will remain so in perpetuity. If that is the case, the only questions to ask in an interview are the desired salary and optimal date to start work.
My actual belief is that software development is exactly like every other skill we observe.
When measured, some people are better than others. Some people are hopeless. Some people are brilliant.
When people set out to improve their skill, some people improve greatly, some do not.
I believe these two statements are consistent with what I have written on this weblog, while what you have written is not consistent with what I have written on this weblog.
Well, you have taken huge liberties with what I have written here. You are, to put it mildly, arguing with yourself.
If you believe that people can be taught, if you believe that "people can get better with time," then YOU believe that some are better than others for a particular task on a particular day.
The alternative belief is that all developers are exactly equal to each other and will remain so in perpetuity. If that is the case, the only questions to ask in an interview are the desired salary and optimal date to start work.
My actual belief is that software development is exactly like every other skill we observe.
When measured, some people are better than others. Some people are hopeless. Some people are brilliant.
When people set out to improve their skill, some people improve greatly, some do not.
I believe these two statements are consistent with what I have written on this weblog, while what you have written is not consistent with what I have written on this weblog.
I think working with logic all day makes us try to frame the world in nice clean unified theories. Some programming is simple, so better tools really really help. Some programming is complicated, the tools often just get in the way. It all really depends on what your building. I've always like the categories: lightweight, mediumweight and heavyweight, but any breakdown that is greater than 2 is useful.
On the other note: if you dig into anything deep enough, you'll probably find some type of contradiction (mathematics excluded) :-) Paul seemed to have missed my favorite device, which is pretending you didn't hear and just babbling about something else.
Paul.
http://theprogrammersparadox.blogspot.com
On the other note: if you dig into anything deep enough, you'll probably find some type of contradiction (mathematics excluded) :-) Paul seemed to have missed my favorite device, which is pretending you didn't hear and just babbling about something else.
Paul.
http://theprogrammersparadox.blogspot.com
Paul seemed to have missed my favorite device, which is pretending you didn't hear and just babbling about something else.
My favorite device is a Mouse Trap.
My favorite device is a Mouse Trap.
For some (perhaps intuitive/non rational) reason, i think we are in general looking at the wrong wall.
The are excellent/good/average/poor etc developers. The think is that this NOT a developer property, but a human-being property.
What does a car manufacturer with their bad workers? What does a company with their average customer service's reps?
I have the feeling that most companies, for most of the things produced, use an probabilistic model (QA in many areas is based on analysis of a random sample passing some tests).
I find it interesting that we (software developers) measure quality as a binary value (0=bad, 1=good) when the rest of the world uses a real number for it (48 bits IEEE 854 should be enough for us too ;-)
Cheers!
The are excellent/good/average/poor etc developers. The think is that this NOT a developer property, but a human-being property.
What does a car manufacturer with their bad workers? What does a company with their average customer service's reps?
I have the feeling that most companies, for most of the things produced, use an probabilistic model (QA in many areas is based on analysis of a random sample passing some tests).
I find it interesting that we (software developers) measure quality as a binary value (0=bad, 1=good) when the rest of the world uses a real number for it (48 bits IEEE 854 should be enough for us too ;-)
Cheers!
"If a better language (whatever that means) can make a good programmer better, why can’t it make a mediocre programmer acceptably average?"
You might say a language is better because it better enables you to express your ideas in code. If you don't have any ideas to begin with it can't help you.
You might say a language is better because it better enables you to express your ideas in code. If you don't have any ideas to begin with it can't help you.
I'm not in any position to talk from experience about experiences like this in an authoritative manner, but here's an analogous situation that I can talk about extensively, and so I'll present it as an interesting point of consideration:
Smart college students doing poorly in easy classes.
In my experience, there is a notable subset of extremely "smart" people at my college who do most poorly in "easier" (for the moment, defined as 2-or-fewer credit hour) classes. I'll disclaim that I'm part of this group and then use myself as a case example of motivation.
I, as a self-proclaimed "smart" person of the noted group, am less willing to spend effort on something I cannot deem challenging/useful even despite considerable extrinsic motivation.
Perhaps there is some subset of genius programmers, the type you definitely want to work for you, that cannot invest their interest in the same way unless the language itself is challenging and mind-expanding (or the problem visibly alluring enough).
To complete the analogy, there are also, of course, smart college students who do well in all of their classes, perhaps because they are easily motivated by extrinsic things, or maybe just by the intrinsic desire for success. If it's the intrinsic/extrinsic side, though, then I start to consider if the potential gap of quality of performance between those who are extrinsic and intrinsically motivated.
In short: Intrinsic motivation seems like it might catch a certain subset of smart people (maybe even the better subset to look at). LFSP are like candy for this group. So are interesting problems, if they're presented well. It /is/ the people.
My 2c.
Smart college students doing poorly in easy classes.
In my experience, there is a notable subset of extremely "smart" people at my college who do most poorly in "easier" (for the moment, defined as 2-or-fewer credit hour) classes. I'll disclaim that I'm part of this group and then use myself as a case example of motivation.
I, as a self-proclaimed "smart" person of the noted group, am less willing to spend effort on something I cannot deem challenging/useful even despite considerable extrinsic motivation.
Perhaps there is some subset of genius programmers, the type you definitely want to work for you, that cannot invest their interest in the same way unless the language itself is challenging and mind-expanding (or the problem visibly alluring enough).
To complete the analogy, there are also, of course, smart college students who do well in all of their classes, perhaps because they are easily motivated by extrinsic things, or maybe just by the intrinsic desire for success. If it's the intrinsic/extrinsic side, though, then I start to consider if the potential gap of quality of performance between those who are extrinsic and intrinsically motivated.
In short: Intrinsic motivation seems like it might catch a certain subset of smart people (maybe even the better subset to look at). LFSP are like candy for this group. So are interesting problems, if they're presented well. It /is/ the people.
My 2c.
Bah.
Put a bad driver in an F1 car. I'll give you 100 to 1 that the bad driver won't drive better in the F1 than in the SUV.
On the other hand, there's a reason F1 cars are not SUVs. F1's are faster, capable of greater acceleration/deceleration, more stable and can make curves faster. But only in the hands of a very capable driver.
So's with languages and programmers. Let's take code speed, for instance. You can't beat assembler code for speed, as long as you have a very capable assembler programmer. But in the hands of a so-so programmer, a compiler will probably do better most of the time.
What about reliability? A good programmer in a functional language will seem to make miracles. I don't even want to see what a so-so programmer will do.
And that can go on and on. Databases? Someone good will extract performance from Oracle that will make you wonder if there isn't some cheating taking place. Let a so-so programmer insert hints, create indexes, etc, and I guarantee he will crash the stuff into the ground.
Anyone who's been around long enough and at the right places will know the above to be true. In fact, you can often witness this stuff first-hand when you replace a so-so with a good programmer.
That's why some languages raise the level of mediocre progammers and lower the level of good programmers, while other languages do the opposite. It's just that some languages come with training wheels and others don't.
Honestly, was there even need to discuss this?
Put a bad driver in an F1 car. I'll give you 100 to 1 that the bad driver won't drive better in the F1 than in the SUV.
On the other hand, there's a reason F1 cars are not SUVs. F1's are faster, capable of greater acceleration/deceleration, more stable and can make curves faster. But only in the hands of a very capable driver.
So's with languages and programmers. Let's take code speed, for instance. You can't beat assembler code for speed, as long as you have a very capable assembler programmer. But in the hands of a so-so programmer, a compiler will probably do better most of the time.
What about reliability? A good programmer in a functional language will seem to make miracles. I don't even want to see what a so-so programmer will do.
And that can go on and on. Databases? Someone good will extract performance from Oracle that will make you wonder if there isn't some cheating taking place. Let a so-so programmer insert hints, create indexes, etc, and I guarantee he will crash the stuff into the ground.
Anyone who's been around long enough and at the right places will know the above to be true. In fact, you can often witness this stuff first-hand when you replace a so-so with a good programmer.
That's why some languages raise the level of mediocre progammers and lower the level of good programmers, while other languages do the opposite. It's just that some languages come with training wheels and others don't.
Honestly, was there even need to discuss this?
Daniel:
Honestly, was there even need to discuss this?
Uh… What exactly do you think this post was about? I thought it was about ad hominems, and consistency, and about disagreement.
The responses here remind me very much of the posting about FizzBuzz. You write that 199 out of 200 people applying for a job cannot write FizzBuzz, and 199 out of 200 responses are implementations of FizzBuzz!
Honestly, was there even need to discuss this?
Uh… What exactly do you think this post was about? I thought it was about ad hominems, and consistency, and about disagreement.
The responses here remind me very much of the posting about FizzBuzz. You write that 199 out of 200 people applying for a job cannot write FizzBuzz, and 199 out of 200 responses are implementations of FizzBuzz!
We are dealing with a function of several variables, of which you have named two, and others include properties of management, co-workers, health...
But humans aren't that good at comparing things of many dimensions/variables. We can't define "greater than" even for complex numbers. Comparing two noisy graphs is nontrivial.
But what do we mean by good anyway? Productivity (KLOC)? Ability to produce maintainable code? Maintainable by whom? Fitness for purpose? Timeliness?
The word processor makes writers more productive than a typewriter in terms of words, but they can get lax about really reviewing and editing the prose. The function of the variables, as well as each variable, is hard to measure.
I would suggest that you are more complicated than a formal system like mathematics, to which the incompleteness theorem applies. So why should you be consistent if such a system isn't provably so? Yet inconsistency may be part of a greater consistent whole: electrons behaving as waves is "inconsistent" with them being particles. A object fitting neatly in a triangular hole, and a circular hole....
But humans aren't that good at comparing things of many dimensions/variables. We can't define "greater than" even for complex numbers. Comparing two noisy graphs is nontrivial.
But what do we mean by good anyway? Productivity (KLOC)? Ability to produce maintainable code? Maintainable by whom? Fitness for purpose? Timeliness?
The word processor makes writers more productive than a typewriter in terms of words, but they can get lax about really reviewing and editing the prose. The function of the variables, as well as each variable, is hard to measure.
I would suggest that you are more complicated than a formal system like mathematics, to which the incompleteness theorem applies. So why should you be consistent if such a system isn't provably so? Yet inconsistency may be part of a greater consistent whole: electrons behaving as waves is "inconsistent" with them being particles. A object fitting neatly in a triangular hole, and a circular hole....
Interesting post. Let's try using a similar example from another field to see if we can come to a conclusion.
Carpentry. Which has greater effect, the carpenter or their tools? If we think about the history of carpentry, we remember that a person would progress through various skill levels from novice to journeyman to master. Along the way, the tools really didn't change. Maybe once in a while you came across a new tool, but it was easily understood with some instruction in its use.
In this scenario, it is easy to see that the difference between carpenters relied on the skill of the individual and not the tools. Granted, if one carpenter only has a hammer and another has every tool created, then most likely the second will be more productive than the first.
It's at this point that it appears that we have some clarity. We can only determine who is more skillful when the people we are comparing have the same tools available to them.
I believe the same can be said for developers. Given the same tools, the developer's individual skills win out. With a mismatch of tools, it is indeterminate.
Look at the scenario this way:
Half of all programmers are below median and half are above. Overall, the majority are NOT great; however, they are craptastic to good enough. As an employer, you have to assume most, if not all, of your programmers will come from this range; therefore, the best plan is to invest/acquire the best tools possible and provide them as a standard tool-set to all of your developers.
This will accomplish three things.
1) link individual performance to skill
2) place people according to skill
3) acquire characteristics to identify skill level
Carpentry. Which has greater effect, the carpenter or their tools? If we think about the history of carpentry, we remember that a person would progress through various skill levels from novice to journeyman to master. Along the way, the tools really didn't change. Maybe once in a while you came across a new tool, but it was easily understood with some instruction in its use.
In this scenario, it is easy to see that the difference between carpenters relied on the skill of the individual and not the tools. Granted, if one carpenter only has a hammer and another has every tool created, then most likely the second will be more productive than the first.
It's at this point that it appears that we have some clarity. We can only determine who is more skillful when the people we are comparing have the same tools available to them.
I believe the same can be said for developers. Given the same tools, the developer's individual skills win out. With a mismatch of tools, it is indeterminate.
Look at the scenario this way:
Half of all programmers are below median and half are above. Overall, the majority are NOT great; however, they are craptastic to good enough. As an employer, you have to assume most, if not all, of your programmers will come from this range; therefore, the best plan is to invest/acquire the best tools possible and provide them as a standard tool-set to all of your developers.
This will accomplish three things.
1) link individual performance to skill
2) place people according to skill
3) acquire characteristics to identify skill level
Sounds like your argument isn't contradictory, but as-yet-unresolved.
You have two theses;
- product quality correlates with programmer skill
- product quality correlates with language power
These may both be true. The conflict is that you've left out how programmer skill and language power are entangled together, to produce good programs.
If you can find that synthesis, then both the earlier theses are OK.
You have two theses;
- product quality correlates with programmer skill
- product quality correlates with language power
These may both be true. The conflict is that you've left out how programmer skill and language power are entangled together, to produce good programs.
If you can find that synthesis, then both the earlier theses are OK.
<< Home
