Posted by andy Mon, 13 Feb 2006 14:16:00 GMT

I have moved my own development mostly to dynamic languages Ruby and Python, and I can see that these languages have had a big jump in popularity over the past year. This is not a fad. It is a very real and permanent response to increasing developer productivity.

Most people learned to program with Basic an older dynamic language. Dynamic object-oriented languages like Lisp/Scheme and Smalltalk have been around for decades and have always had a cult following. The highest productivity hackers have always appreciated the things that make them dynamic: that changes to code are interpreted immediately, and that objects can be modified at runtime and in real time.

The key observation is that these are the highest productivity hackers. They are the guys that program so quickly that they need immediate feedback on builds, rather than daily or weekly. They also dont feel the need to do a lot of planning around their code, since they figure they can fix anything that goes wrong on a similarly short cycle.

Other people did not feel the limitations of their build cycle so acutely, and they tended to avoid dynamic languages because of their limitations in speed, stability, and resource usage during actual deployments.

I hypothesize that the demand for dynamic languages is driven by developer productivity. When the amount of work that you can do in 30 minutes goes over a certain threshold, the build cycle itself becomes a limitation, and you want a dynamic language.

What if the merely good programmers started moving as fast as the exceptionally fast programmers? There are a lot more merely good programmers than exceptionally fast programmers. What if the WHOLE CURVE shifted? Then the demand for dynamic languages would skyrocket as the majority of programmers found they needed them. That is exactly what is happening. Programmer productivity is increasing.

For 40 years, programming was assumed to be a labor-intensive activity with very low productivity growth. Computers got faster and faster, but developers still required the same amount of time to produce a function point. The problem was exacerbated by the fact that projects got bigger, and bigger projects have inherently lower productivity per individual. And, there were a lot of inexperienced developers coming into the labor pool, which slowed things down. So several factors conspired against productivity increases.

However, I believe that something changed in the mid or late 90s, and developer productivity started increasing much more rapidly. Adding to the momentum, the bust of 2001 forced everyone to get better. I intuitively estimate that developers are at least twice as productive now than they were six years ago.

Why did this happen? Im not sure, but improved tools, computers, processes, accumulated knowledge, and the availability of free software, may have finally had their intended effect.

The increase in productivity is now being amplified by other factors. When software gets standardized and broken up into Web services, project sizes can get smaller, which adds another boost to productivity. Offshore developers who can rapidly and at low cost jump into a project push up productivity per dollar even more. Open source software means more code re-use, which really pushes up productivity. Finally, the availability of audiences that are willing to absorb beta quality software has compressed release cycles.

The evidence can be found in the structure of the industry, where development team sizes are shrinking, implying an increase in productivity per developer. Ruby is an interesting case. The language is essentially developed by one person. Rails is developed by a very small group. These guys can have asmuch impact as much bigger java teams did in the 90s.

So, there is a whole cluster of phenomena that come from the same root cause of increasing developer productivity: smaller teams, shorter release cycles, and the use of dynamic languages. Its a permanent shift. It affects all of the tools we use, the ways we organize ourselves, and the structure of the software industry.