It is well known 10 good developers can produce more and in better quality than 100 average developers [1, 2]. It is not a matter of maths, instead of simple psychology: Software is a people’s business. All agile methodologies agree unanimously on the central role people have on Software Development.
The idea of getting a bunch of developers, put them together and hope everything will go fine is nothing but wishful thinking. Projects fails all the time, run out of money or simply get stuck. Some drag as long as the company has money to throw at it. And yet Software Development continues to prosper and the need for developers increases, with no end at sight.
Software became a basic need for any business. Not having a web-faced business or a software enhanced business is commercial madness. “Every business is a software business”, paraphrasing a CEO I met not long ago.
Software’s fundamental role justifies the continuous investment and considerable budget allocated to it. Its necessity exceeds its failures and waste, allowing for the Software industry to grow and flourish.
Software Development has nothing to do with industrial production. Waterfall was based on that wrong assumption: a few good minds do the thinking and the rest to type the code. The accurate comparison with the production phase is the generation of the executable artifact, an automated task usually made by the CI server.
Every change made to the code is the creation of a whole new product, not a repetitive task. Software is constantly being redesigned. Rethought and redesigned. Developers have to maintain a mental map of the system, built over time from continuously working with the code . The clearer the map, the better its redesigned. Too little redesign ends on deficient and low quality systems, hard to understand and maintain, A.K.A. legacy systems.
How is it possible to measure developers productivity? By number of minutes spent at the keyboard? Number lines of code? How do you compare work done by different developers? How to compare quantitatively tasks complexity and outcome quality?
Someone directly involved in development process will be able to the answer those questions, but the answer formulation will resembles more a pie judging contest than a scientific method.
The overall productivity of a team is more important than individual one. For a collective sport as football, evaluating teams is much easier. From watching a football match it is possible to notice when the team is not working. It is also possible to spot which players get along, the prima donnas, the talented, the experienced and the leaders. Software development teams are teams and have the same human dynamics.
Every morning I go across Liverpool Street station in peak hour. Not the best way to start the day crossing a chaordic flow of people. It bears no resemblance with the coordinated flight from a flock of birds. Everyone has different speed, direction, objectives and way of thinking.
We are unique on the differences we have from everyone else as a whole and a striking resemblance on an individual basis. We are all just humans: error-prune, emotional and inconsistent . “We have to do less mistakes” is a paradox, as no one fails intentionally.
New technologies appear on an amazing rhythm, but we remain the same. Changing the way people think is cumbersome and painful. Changing human nature impossible. Fighting human nature with processes is a common pitfall in Software Development.
No man is an island
I remember a few years ago coming across a software company with one single developer. Yes, the mythical one man team! It is the perfect scenario: communication is flawless, everyone agrees on everything, has same working hours.
Software systems complexity increased beyond the point a single developer or even a small team can tackle. No company can survive from the work done by one single developer. Working in team and with other teams is a unavoidable reality.
It is expected from group of individuals, like the ones crossing Liverpool Street station every morning, to build complex software systems together. Many solo attempts are made as an alternative to work as a team: developers rewriting others work or developing a strong ownership over specific part of the system. They will never be part of a team, just part of a group of individuals. No arbitrary number of individuals can outperform a Team.
Software systems are amongst the most concrete and complex systems built by man. Everything is reduced to a well defined immutable set of instructions.
In contrast, Software is made by people for people: People Inc. Its creation is a fuzzy process of trial-error. The outcome varies considerably from person to person, team to team, company to company.
This duality makes Software Development one of its kind. Establishing parallel with others industries is dangerous. You can’t double productivity by doubling the number of developers . Different teams will not work the same way nor produce the same amount of work. Math and logic do not apply to people.
 “Agile Software Development: Software Through People” – Chapter 2 “Individuals”, Alistair Cockburn, Addison Wesley, 2001
 “The Mythical Man-Month”, Frederick Brooks, Addison-Wesley, 1975
 “Computing: A Human Activity”, chapter “Programming as Theory Building”, Peter Naur, ACM Press/Addison-Wesley, 1992