Mythical Man-Month

In his comments to the MMM edition after 20 years, F. Brooks writes:

Some readers have found it curious that MMM devotes most of the essays to the managerial aspects of software engineering, rather than many technical issues. [...] it sprang from a conviction that the quality of the people on a project, and their organisation and management, are much more important factors in success than are the tools they use or the technical approaches they take. Subsequent researches have supported that conviction. Boehm's COCOMO model finds that the quality of the team is by far the largest factor in its success, indeed four times more potent than are the tools they use or the technical approaches thay make. [...] (MMM, p.276)

What is the role of the language/technology, then?

The central question of how to improve the software art centers, as it always has, on people. We can get good designs by following good practices instead of poor ones. Good design practices can be taught. Programmers are among the most intelligent part of the population, so they can learn good practice. [...] Nevertheless I do not believe we can make the next step upward in the same way. Whereas the difference between poor conceptual designs and good ones may lie in the soundness of design method, the difference between good designs and great ones surely does not. Great designs come from great designers. Software construction is a _creative_ process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge. The differences are not minor -- it is rather like Salieri and Mozart. Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude. (MMM, p.202)

Note the phrase on "sound methodology"; this is the soundness and freedom that some languages tend to offer and some tend to forbid.

Peopleware

T. DeMarco and T. Lister in "Peopleware" look at the topic at length. They conducted for several years a study of programmer productivity via "coding war games" to find that there is little correlation with language, years of experience, number of bugs people made, and salary. The correlation was interestingly enough mainly with the organisation the people worked at. They discovered a "clustering" effect: two people from the same organization tended to perform alike. Best organizations attracted best programmers, and vice versa. The productivity ranged from 1 to 10 among different organizations, so the effect was not negligible. When you are programming in the large, it's all about people.