Banner Zenit, Scientific & ICT Services

Drowning In Methodologies

Translation of Metodologías hasta en la sopa by Juanjo Navarro


Each year a large number of methodologies crop up promising to solve the software crisis. What can we expect from these methods? Do they deliver what they promise?


Our profession is very given to methodologies. It seems that not a year passes by without at least ten new revolutionary methodologies being launched that promise to solve the infamous software crisis at a stroke.

We only have to attend a computing conference, take a glance at any forum about the subject or read a few web sites to hear talk of miracles from a thousand and one methodologies. Their gurus, like true monks of new religions, tell us about the exponential improvement in productivity that we can expect from their systems. They present comparative studies where they show that for project X in company Y, one in which their methodology was applied in an experimental way, they managed to complete a large project as planned, or even faster than planned, something that is very rare in the world of software development.

Let us pass over the fact that in many of these studies the scientific method is conspicuous by its absence, that the majority of programmers have never heard of control groups, of productivity metrics and the other paraphernalia of basic science. Let us pass over the fact that developers, desperate to achieve the best results, are easily converted into believers and put the basic rules of logical skepticism aside. After taking all this into account, wouldn't it be a bit strange if there was not a hint of a real improvement in productivity behind these studies?

Do they all work?

In almost every case, if we talk with the participants of these proof of concept projects, everyone appears to be delighted. Programmers, project managers, users and clients all seem convinced of the benefits of the methodology, of the positive results of the methodology on their project. The development time was reduced, the users' requirements were met and the usability of the system was high.

How can this be? Let's try to understand this. I am not saying that none of the methodologies have delivered real benefits. But all those methodologies? Some systems claim that you need more documentation, others say that you should reduce documentation to a minimum. Some methodologies propose improving programmer productivity by giving them private offices and peace and quiet, whereas others say that all the work should be done in pairs and that all the team including users should be together in the same room in order to encourage the creative juices to flow. Each methodology is different from the others, but nevertheless each one promises to improve productivity. How is this possible?

The Hawthorne effect

Between 1927 and 1932 a study was conducted in the Hawthorne plant of the Western Electric Company in Cicero, Illinois. The study investigated the effect on productivity of environmental changes introduced by the investigators. The investigators found that when they increased the light intensity in the plant, productivity improved. The surprise was that when they reduced the light intensity, productivity also improved. Almost any change they made to the method of work in the plant resulted in an improvement in productivity.

How could this be? The main conclusion from these studies was that the workers enjoyed the attention they were getting during the study and worked better as a result. The other similar conclusion was that any novelty introduced into the system of work improved things; people are bored with doing things in the same way all the time and they like change.

This finding has come to be known as the Hawthorne effect.

Could it be the Hawthorne effect that is producing the improvements claimed by each and every one of the new methodologies? This would appear to be consistent with the long term results where methodologies often do not continue to deliver their initial productivity improvement when they become the routine method of working and are soon forgotten.

The book, Peopleware, one of the more influential books about project management in our field, describes the effect and shows us how we can take advantage of it; companies like Fujitsu have turned novelty into the norm and they introduce some experimental change in all their projects in order to keep the workers on their toes.

Let's be aware of what each system is capable of bringing into our daily work, let's be creatively skeptical about these systems, applying only that which is really going to help us in our task and let's leave to one side any miraculous recipes that we hear about. And let's not forget to enjoy the work. Being faced with a boring programming tasks is what really reduces productivity. Some small new idea introduced into every project really can do more for productivity than any of the existing methodologies. [Translator's note: And don't forget that it is the genuine interest and attention from management in the work of their staff that is the essential ingredient in making the Hawthorne effect work its magic.]


Return to Extracts from Planeta Código


© 2005-6