Carl Erickson observes that a small, boutique team of developers can be massively more productive than a larger team.

To complete projects of 100,000 equivalent source lines of code (a measure of the size of the project) they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

Its immediately reassuring to see those numbers, since I\'ve been on enough projects that, once they start falling behind, the temptation to throw more programmers at it grows. Project managers see it as a resource scarcity problem (not enough programmers) and don\'t realize that coordination and communication burden that they adding by bringing more people on to a project. Now you have a new group of programmers that need to be brought up to speed, learn the codebase, and accept design decisions that have already been made. You\'re lead programmers won\'t have as much time to actually program, since they\'ll be helping bring everyone else up to speed. Developers have known about this for years, Fred Brooks wrote the book in it - The Mythical Man-Month.

But while the study\'s conclusion is reassuring, I wonder if there are other factors at work. Theres an obvious selection bias in the type of people who go to work at a large IT programming department/shop versus those who choose to work solo or in smaller teams. Are large teams filled with junior 9-5 programmers who just want a steady job but punch out in the evening? Do smaller teams attract more experienced and productive people who prefer to work smarter rather than harder? From the study summary, it doesn\'t look like they considered this aspect.

Perceptive and made me chuckle.

Meanwhile my smartphone will be lucky to survive 34 months, and is only able to receive commands from Earth if I hold it out of an upstairs window...

Source

Finally. This is a huge step forward for Drupal. After eschewing OOP practices for a long time, its finally winning over core developers, which will make working with Drupal as a Framework easier in many ways. I copied the announcement below, but you can see that patch and discussion here.

This patch is about to be committed. It is the foundation to change for example \$comment from an stdClass to a comment specific class allowing for \$comment->save(). This is a monumental change and everyone is invited to review and familiarize with the new system even before it is committed.

What is possible when you use proper classes? The first thing I envision is a plugin/pluggable system in the same way that Zend Framework allows you to use Controller Plugins and View Helpers from a pluggable object, without the need to inherit or compose an object. For example, in a Zend View, you can call a partial like this:

{syntaxhighlighter php}

partial(\'my-partial.html\'); ?>

Now, the View class doesn\'t have a method named partial, instead the magic __call method intercepts the call, gets the Partial view helper, and calls its invoke method.