People Inc.

It is well known a handful of developers can produce more and in better quality than groups several times bigger [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.

Bare necessity

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 production

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. 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 [3], called tacit knowledge. The clearer the map, the better its redesigned. Systems with too little redesign have low quality and become hard to understand and maintain, A.K.A. legacy systems.

Industrial mass production techniques cannot be applied to Software Development [4].  Employees do not execute repetitive well-defined tasks, are not easily replaceable and will shape the final product. History taught us a mastermind to tell everyone else what to do doesn’t work. And yet it’s still a common scenario.

Software productivity

How is it possible to measure developers productivity? By number of minutes spent at the keyboard? Number lines of code? [5] How do you compare work done by different developers? 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 and is easier to evaluate: the more productive a team is, the more profit its work generates. This evaluation is only possible after work is well-under way and a considerable investment is already made. There is no of way of guessing how a team will perform. Even worst, it’s hard to know when a team is not working, understand why and make it work again.

If it was a collective sport as football, assess teams could be done by watching a football match. You could spot which players get along, who compromises outcome, the prima donnas, the talented, the hardworking, the experienced, the leaders… Software development teams are teams and have the same human dynamics. You have to do constant unbiased attention.

Just humans

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. Everyone has different speed, direction, objectives and way of thinking.

We are unique on the differences with everyone else as a whole and a striking resemblance on an individual basis. We are all just humans: error-prune, emotional and inconsistent [1]. “We have to do less mistakes” is a paradox: 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 the 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. But they will never be part of a team, just part of a group of individuals. No arbitrary number of individuals can outperform a Team.

Conclusion

Software systems are amongst the most concrete systems built by man: everything is reduced to a well defined immutable set of instructions and the result is extremely visible. 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 [2]. Different teams will not work the same way nor produce the same amount of work. Math nor logic apply to people.

References

[1] “Agile Software Development: Software Through People” – Chapter 2 “Individuals”, Alistair Cockburn, Addison Wesley, 2001

[2] “The Mythical Man-Month”, Frederick Brooks, Addison-Wesley, 1975

[3] “Computing: A Human Activity”, chapter “Programming as Theory Building”, Peter Naur, ACM Press/Addison-Wesley, 1992

[4] “Peopleware”, 3rd Edition, Chapter 2 “Making a Cheeseburger, sell a Cheeseburger”, Tom DeMarco and Timothy Lister, Dorset House Publishing, 2016

[5] “-2000 Lines Of Code”, Folklore – The Original Macintosh, Apple, https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s