Would he deny that there are good programmers who can do things that bad ones couldn't no matter how much time they were given? This is true in other fields; why should programming be any different? And if one programmer can be infinitely more productive than another, he can also be 20x more productive.
They would only be 20 times better or infinitely better at those particular tasks though.
That seems right to me, it seems like only really Hard problems allow people to show what they are made of, and the easier problems keep the pack more bunched together.
It's an important distinction, because a lot of programming is not of the demanding sort described above. It might even be that for some jobs, in some job markets, you don't want to try to hire the best. The cost in salary, recruitment, lost time and turn over might trump the 2-3x gain a top level programmer would offer in a non-challenging environment.
There are tasks that are strictly defined from the outset: there is an existing code base and tech stack, and you must conform to certain company conventions, and the requirements are strict. I would guess this work constitutes 90% of paid development (and ~2% of useful code). I don't think your argument really applies to those tasks.
Yeah the problem is the scope of the problems he's imagining. Given a task that takes a great programmer several months to complete, I can easily imagine a team of average programmers taking man-years to complete it. The open-source community is full of such projects and before anyone says they are all copies, so are most average software company's products.
There isn't much data on single average programmers taking years to do projects because they just don't work alone and on one project for that long. A mean measure probably isn't a good way to break down the difference as it's likely to be infinite far too often.
But I think his point was that those people who can't solve those problems in infinite time are at such a low end of productivity that almost every decent programmer is some coefficient c better than the one that can't do it, where c >> 10.
There are tough problems in programming, but unless you are breaking ground in p-np complete type proofs, are there really any day to day problems in almost any development setting that a decent programmer can't attack?
Look at the graph referenced - it describes, on a scale of hundreds of minutes, how long it took programmers to implement something to spec.
My biggest problem with this is the time scale. More advanced programmers build generalized solutions to problems and build on previous abstractions. There's no clear limit to how clever someone can be while building abstractions, so the gap between programmers will become greater over larger time periods.
Taking a sample of developers creating small, custom websites, better developers will have factored out a lot of functionality into a general purpose web development kit with metaprogramming by site #3 (i.e. created a Django, Rails).
Is it unreasonable to accept that:
1) Creating a site with a decent web tool kit is 20x faster than rolling your own with mod_python, and
2) Metaprogramming for creating an (elegant) web tool kit is beyond the abilities of a section of programmers?
Now, the barrier to picking up Django or Rails is much lower than writing one, so perhaps this advantage is somewhat less important in a world with open source and extensive libraries?
Well, I would argue that in a way, the efforts of the creators of Rails and Django have been multiplied so many times by all the users that they, in effect, have increased global productivity by a factor so large it dwarfs the productivity of a single programmer - so their 'productivity', as measured by the impact they have on the world, is a hell of a lot more than 20x the impact of Mr Blub programmer in the cubicle next door.
Why stop at frameworks? What about languages? What is Guido van Rossum's impact on global value delivered by programmers? What about the developers of the microchip? I'm pretty sure my personal productivity would be lower without that. The invention of the internet, which allowed for free sharing of knowledge? What would the productivity of a programmer who invents general purpose AI be? It really depends on how philosophical you want to get.
So, sure, the difference between developers creating an application to spec on the time scale of hundreds of minutes is unlikely to be 20x. But that's a garbage metric, and as always, GIGO.
What about PHP, though? The crappiest, least abstracting language seems to be the most productive one. Perhaps abstractions really are just bullshit? I like abstractions, but while I am busy thinking about my abstractions, the PHP coder has already churned out another three no-brainer pages.
Well PHP was written by someone, too, and that improved productivity over what came before (CGI/C++?). Django and Rails aren't really central to my argument - they can be replaced with any language/library/framework that boosts productivity.
Careful about saying 'least abstracting' though - if it really is faster (not my experience, but assuming it is), then although it might not appear to be a powerful abstraction, it actually is, at least in some way.
Your abstractions (done well) are exactly what I'm talking about - long term productivity. Given 100 minutes you may well be well behind (if you've even started actually coding), but will that still be true 100 days later if the other guy is writing it in straight, hackish PHP?
Nevertheless, PHP seems to be by far the most successful programming language for web applications. I also don't think that maintenance time was ever measured for typical production time studies.
Most of the recently hyped web applications are written in PHP, for example Facebook. Wasn't there a list recently with the 10 most successful startups (by whatever criterion), and 7 out of 10 were based on PHP?
That's not because PHP is especially great, today, but because there weren't any decent alternatives in 2004.
Rails is three-and-a-half years old, as a public project. The alternative frameworks are about the same age. There are programmers with ten years of PHP experience; there is nobody on Earth with so much as three years of Django experience. Give the newbs some time to settle in before you declare PHP's long-term victory. PHP has had a long headstart.
To have a successful startup that makes a 2007 list, you have to start learning programming before 2007. Back in 2003, PHP was pretty much the name of the game, unless you enjoyed being married to Microsoft or wanted to construct vast mountains of overdesigned, stateful, undeployable Java middleware. Or unless you were writing your own framework from scratch in an alternative language, like DHH, or the Django folks, or the Redditers.
Certainly food for thought. I think the author underestimates just how bad some programmers are, though. To me, his assertion that there is some arbitrary limit on the productivity differential between any two given programmers is much harder to prove than the assertion that there exist some programmers who are 20x better than others.
There are definately some programmers who are 20X better than others, but I think the authors point was that the 20X difference is between programmers who are 3X above average and programmers who are multi-X BELOW average. The myth is that there are some super-coders who are 20x better than your average decent programmer, and I think that would be difficult to substantiate.
> find me a peer-reviewed study of individual programmer productivity among professionals not students
Often, five man development teams create products that are very successful while thousand man development teams create a product thats useless and basically has no value. Thus the five man teams were way more productive. This happens all the time.
Also, the same principal can be seen on an individual level within projects.
There ya go pal. It would be a waste to do a peer reviewed study just to confirm something so obvious. You could even say that they reviewers would be "less productive" if they spent their time doing so;)
Making any kind of assumptions like this is retarded. The coder umbrella covers too much. Assembly line coders in a large corp are completely different than a freelancer etc. Different skills, different motivators, just plain different. Comparing the two is like comparing two completely different fields... because they really are different fields.
Like comparing automotive designers and mechanics.
Coder is just too big of a blanket. Articles like this are irrelevant.
He's right that almost all the discourse on this topic is anecdotal and that the literature basically sucks. It's surprisingly difficult to find hard evidence for the claims people make about software development. The only good, readable source I know is Robert Glass' Facts and Fallacies of Software Engineering, which systematically cites research, most of which is surprisingly weak.
Nice article as far as it goes. I've always felt that the productivity of all developers is affected greatly by all the other mundane tasks that surround the programming - communications, deployment, answering the phone, logging in, futzing in general - and that they are much better targets for productivity improvement.
That's why I find the recent rails vs. php deployment discussion very interesting. I've been working on a django app for a while, and while I enjoy the language and framework, I suspect any (slim) productivity increase I have gained will be negated by the deployment.
I am addicted to programming for startups. I have learned from 1st hand experience and from CVS logs that on most projects 99% of the check-ins and real coding is done by at most 2 guys (usually 1) on a 8-10 man project. I would say, even though I haven't done a study, I see the hard facts every time I check-in code. There really are programmers out there 20x-30x more productive than the rest.
He lists C++ and C# as his favorite languages, and I tend to agree that with these languages you can't really be x100 more productive than the average competent programmer.
That kind difference is only possible in languages that are more expressive & condensed, where you spend most of your time thinking not typing.
Come on, that has to be bullshit. I sympathize with the new "power languages" hype, but it can't be that much of a factor. Even with C++, C# or Java, you spend most of the time thinking. You don't even type all that much, because of the IDE support...
Actually I recently thought about the "dependency on IDE makes you miss out on cool languages argument", and you could basically just turn it on it's head: rejecting IDEs makes you miss out on a lot of cool features, too.
So on an every decent sized project in one of those languages most of the code is boilerplate code you didn't even write but which wastes your time and brain cycles when you tinker with the code.
Another interesting statistics that has been researched throughly is that productivity in LOC/hour is pretty much constant for programmers in all languages, which pretty much translates into higher productivity with more condensed languages.
Well, most of the code isn't boilerplate code. the LOC/hour statistic would interest me, is there a reference?
Also, the condensed style of scripting languages might waste more brain cycles than more verbose code when trying to understand it? I enjoy the condensed style and clever things you can do with it. But clever things have a tendency to also require cleverness when trying to understand what they do.
I had a discussion on this topic last night at the St. Louis Ruby Users Group. The consensus we came to was that code is not an asset; it is a liability. Features are assets. The fewer lines of code you have to write, test, and maintain, the fewer bugs you will have, and the less effort you need to expend on things like refactoring and maintenance.
Boilerplate is a sickness. Even if your IDE is generating it for you, you still have to read, interface, and interact with it in your daily operations. Any higher level abstraction which allows you to remove boilerplate and redundancy leads to greater robustness and flexibility in your software.
I'm not saying that playing golf with your code and turning it into line noise is a solution. That merely results in higher level of complexity rather than a higher level of abstraction. It becomes brittle. But when you can apply more powerful concepts to the solution of a problem, fundamentally complex operations can be expressed in a simple manner.
New abstractions definitely have a learning curve. I believe that this is a separate effect from mere cleverness or an obfuscating complexity. The advantage of this learning curve is that once the concepts are understood, future effort is eased and the new principles become natural expressions of solutions. A professor of mine once told me that Mathematics is driven by the creation of new, more powerful notations. Being able to describe an idea in a more succinct way leads to the ability to reason about a problem space and discover the underlying fundamental principles of its operation.
It may well be the case that it takes a more dedicated, talented, or skillful person to write code at higher levels of abstraction. The innate curiosity and insight needed to pursue the greater goals of software excellence can be distressingly uncommon. I believe that the balance of the issue is offset by the force-multiplying effect of powerful languages, designs, and abstractions as well as the social effects of being able to accomplish more with fewer people. Reducing the social and management overhead of a project results in greater individual productivity, improved group cohesion, and more effective communication.
Any approach which can eliminate the extraneous details from the expression of the solution to a problem and which allows us to work with the raw core of its nature enables us as computer scientists and software engineers to deliver more robust, effective, and elegant software solutions.
And you might even find yourself to be happier while doing it.
Don't get me wrong, I am also curious about the "new" wave of programming languages. But Perl was also dynamic and very brief, and I remember being VERY glad to switch from Perl to Java. Suddenly code worked the way I thought it would work, not some other weird way. That memory sticks with me, and therefore I take the dynamic typing hype with a grain of salt.
Maybe the "Boilerplate" aspect of Java is a bit overblown. There are interfaces, but I think they are a necessity because of static typing (how do Scala and Haskell deal with it?).
So it is really the pros and cons of static and dynamic typing that are to be discussed. There are boilerplate things like the awful EJB stubs, but everybody hated them from the beginning, and I for one managed to avoid using them for all those years. They are not Java, just something stupid somebody implemented with Java. You could also create a horrible framework with lots of boilerplate code for Ruby, after all.
What else? OK, the new generics are too verbose, I hate them, too. And then there are the curly braces and mandatory brackets for function calls, but I think that can't be what everybody hates (Ruby is more verbose with do end instead of brackets, isn't it?).
It's not about fewer lines, it's about fewer layers. If you can abstract out portions of the code with your more powerful language, you can test it independently and know it works, then build on it. The fewer layers you have to hold in your head, the easier the code is to modify and maintain.
Really productive programmers win by writing themselves APIs as they go. These can be reused in the future (hence the productivity multiple grows over time). As PG and others have said multiple times, you can be way more productive if you design a language for the problem domain, then use that language to solve the problem. That is what more powerful languages allow you to do.
It's not so much about trying to condense lines of code, it's about how many things you have to focus on at once (the fewer things you need to pay attention to, the easier it is to work with). Since any modern language handles all the minutiae of disk access for me, I can read and write to files with one or two lines. I don't have to care how it's done.
If you think I'm just stating the obvious, I rewrote a project in my last job in about three weeks that took the original team of four people two months to implement. The only thing that allowed me to achieve that kind of speedup was that I used an existing SOAP library (this was a web app with a web service back end for the data) instead of all the kludgy custom XML parsing they were doing. They had different code on each page of the web app for handling the webservice calls. It may sound retarded (because it is), but I have seen that kind of situation a hundred times, so I have to believe that that is the kind of code the average programmer churns out.
I don't claim to be a rockstar either. I know I've written a ton of horrendous, kludgy, redundant crap in my lifetime too. I think it just happens when you don't have a clear idea of what the end product will be, and don't take the time to refactor as you go.
