The Joel on Software Discussion Group (CLOSED)

I was writing a blog entry prompted by Augustine's Law #5 (1/10 of the workers produce more than 1/3 of the output) and it set me to wondering: is that productivity ranking intrinsic or situational?

Joel cites data from Professor Eisenstat at Yale that the time to complete projects varies widely, even among those who score well on the projects.  We can consider time to complete to be inversely proportional to programmer productivity if we assume that the longer times do not relate to additional capability in the software produced.

My question is whether the relative productivity of individual programmers varies over projects?  Is programmer A always roughly twice as productive as programmer B or does it matter what project they are working on?  That information should be available from Professor Eisenstat's data (assuming that scores are attached to individuals).

I've always assumed that programmer productivity varied by subject matter (someone who knows 3D math is likely to produce 3D display code faster than someone who doesn't) and by some mostly ineffable "temperment" (some people are faster debuggers than others, some produce the first 80% of code faster than others, and some provide the last 20% of polish faster than others).  It would be interesting to see if Professor Eisenstat's data indicates relative productivity varies by project subject matter, apparently randomly, or not at all.

>I've always assumed that programmer productivity varied by subject matter

My own pet theory, not at all based on actual data, is that programmers spend, on average, around 50% of their time learning about both what they have to do and how to do it - looking up things in reference books, tracking down information on the web, implementing small test programs to find out how something works.

I think you're right, but knowledge of the subject matter is only part of productivity. The other part is knowledge of programming technique. A "high notes" programmer will have an easier time writing his data structures and algorithms, no matter what the application domain is.

A "high notes" programmer spends most of his learning time learning about the application domain. A programmer who is an expert on the application domain would probably spend most of his learning time on programming-related issues. I don't think it quite balances out - the "high notes" programmer is probably more productive in the long run.

Some people can solve the problems nobody else can solve. Some people can design complex systems that are easy to maintain and understand. Some people can build trivial stuff amazingly quickly. Different qualities, and all can be tremendously helpful in the right situation.

If you put a terrific kernel-hacker in an environment where he has to write high-level java code for a browser applet that documents the flow of documents in a multinational then he won't be very productive.

So yes, I think it's situational, because people are experts within a domain.

Not all terrific coders speak French fluently either.

Programming is about figuring out what to do and doing it. That applies to all problems. So if you are good at that then it's not situational.

Yet you can always create mismatches. A long distance runnder  versus a sprinter, for example. Someone who has written their 5th game engine versus someone who has never written one. Even in that scenario I would put my money on the better programmer to write a better game engine.

SoP,

The better programmer, given enough time, will undoubtedly come up with a better engine.

But he will first have to make mistakes before he reaches the point where his engine will be superior to the 6th engine of Mr. Average. Maybe he needs only 2 iterations to get there, who knows? I've build a few (elementary) game engines, and the design mistakes I made were caused by insufficient comprehension of OpenGL/Direct3d. I don't see how a genius programmer can avoid making these mistakes, without learning how OpenGL/Direct3d work first.

> But he will first have to make mistakes before he
> reaches the point where his engine will be superior
> to the 6th engine of Mr. Average.

That's why this is a difficult topic. Quality, excellence, beauty, ease of use, etc are not defineable.

If raw functionallity is the key then the high note is features. But there is more to quality than that. Mr. Average  probably will never get that part right, even though the features might be right.

None of the terms we're using in this discussion have been properly defined, so chances are we will never come to an agreement. And if we do agree, it's just a cooincedence.

If you give both programmers 10 years to make the best engine possible, the better programmer will simply come up with a better engine. If you give both programmers a week, then the experience of the average programmer allows him to make something that doesn't completely suck, whereas the good programmer needs the time to wrap his head around issues such as depth buffers, vertex shaders and soft shadows.

You can create a simple engine by stitching tutorials together. It will make a huge mess of dependencies, and a lot of function calls are made that effectively negate eachother, but it will work... sort-of. If a week is all you have it may not seem like such a bad compromise.

An equation with a dozen unknowns is impossible to solve.

> An equation with a dozen unknowns is impossible to solve.

Yet that's what we as humans do every day, and do pretty well.

>>
>>> An equation with a dozen unknowns is impossible to solve.
>>
>>Yet that's what we as humans do every day, and do pretty
>> well.

By defining as many unknowns as necessary in order to make the equation meaningful.

I used to coach track and field and the sorts of physical attributes of what makes a superior athlete can be equated to a superior software engineer. There are some people who have better oxygen uptake and some who have a longer stride length and some who have a quicker leg turnover. But if you can find one with all the above, you have someone who can compete at the highest levels.

In the software game, there are people who can crank out a lot of code quickly and people who can code with minimal errors and people who know how to design for maintainability. When you combine all those attributes, you have someone who can be far more productive than anyone else on the team.

The difference between the athlete and the programmer, however, is that physical traits are innate and work habits are learned. Great athletes are born. Great developers are made, usually self-made because they are motivated.

>Great athletes are born.

They also train very very hard.

No, no, no, I disagree all around.

Most programmers (and indeed, most knowledge worker professionals) are completely stumbling around in the dark, but usually think they know what they are doing. They have a cargo cult mentality; they design by coincidence. Their acheivements are merely a result of inertia.

The "good developers" are just people are supremely adequate. They understand the domain well and more importantly, know their limitations. The very best ones are extremely disciplined and open-minded, and force themselves to schedule and plan and do the things that are not fun, and are willing to throw out old strategies when someone demonstrates something new.

I don't think the specific project matters very much, even if it is trivial. People in the first category can't really be considered to be "productive" if they create something quickly which they don't truly understand. Good developers can outhack any newbie, they are just seasoned enough to know that it's almost always a bad idea to do so.

"Great developers are made, usually self-made because they are motivated."

Great developers are born.  Somebody without a base aptitude for programming will never rise above being a mediocre hack no matter how hard they work at it.  You or I will never become a John Carmack or Donald Knuth no matter how much we work at it.

Great developers are born, but they do have to work hard at it, just like the world class athlete has to train hard.

And as for the original question, I do think the "high notes" is situational.  A programmer great in one domain is likely to be good in others, but they won't quite hit the "high notes" other domains.