This post is somehow a tribute to what is known as Brook’s law in software engineering:
Adding manpower to a late software project makes it later.
In his popular book, “The Mythical Man-Month”, Brook stated something very important that seems to be ignored by many software factories offering their “professional experience”, either in the form of an off-the-shelf software product or by contracting their programming skills: communication.
As in any other activity involving the work of a group of people (note that I don’t want to mention the word team, since it implies to have a higher grade of cohesion. More about this will be discussed in a future post though), interaction is required in order to achieve a common target. In software engineering is exactly the same, it does not matter how this interaction is carried out (email, phone, chat, wikis, bug trackers, etc.), communication is a must.
To the date I had the luck of having worked in quite heterogeneous places with very different setups. When I say heterogeneous I don’t refer necessarily to the fact of being multicultural, but instead in terms of how the communication between the different people involved in a project is developed. In this line, I can enumerate the following so far:
- The solo style. This setup refers to those groups where people are used to work alone, performing any kind of interaction with others only when they cannot continue on their own. Usually the people working in such an environment lack of social skills (shy, too arrogant for asking for help, egoist, etc.), which repercutes directly in the development process implemented. The output is by general rule not good. The source code is unmaintainable (a.k.a. spaghetti code is produced) and the project expectations don’t fit the required level of quality. The biggest problem of this kind of environment is that it is nearly impossible to change its behaviour. Newcomers willing to change the way things work will sooner or later give up and leave, which means that only those with the same nature of the group will stay. This translates in a snowball effect making things even worse.
- The centralised style. This scenario is characterised by the existence of a person who acts as the central hub for every communication between different components of the group. Usually, this person plays the role of project manager and is defined by the need of controlling everything what’s going on in the project. This kind of people have problems delegating tasks to others. Usually the working environment for the rest of developers is ok, but the success and quality of the project depends highly on the grade of expertise of the hub. Newcomers learn a lot in this kind of scenario due to the constant supervision, but some could feel stressed because of being always under surveillance.
- The peer to peer (p2p) style. In this scenario the interaction takes place among all the members of the group, regardless of the existence of a leader or not. The advantage of this scenario resides in the capacity of correcting the behaviour of the group as a whole. This means that newbies can learn the best out of the experienced developers by continuous interaction along the time. The disadvantage relies on managing the amount of communication required between the different peers, which can translate in project delays: “w_hen n people have to communicate among themselves, as N increases, their output decreases and when it becomes negative the project is delayed further with every person added.”_ When this happens, leaders tend to cut down the level communication by reorganising the group in different subgroups for example, which again can result like described in any of these three scenarios.
Of course, one could think about any possible combination of the previous scenarios and I am sure that there are even other kind of situations that can happen when developing software. If you know any of them or have something to add to the mentioned ones, I would love to hear your thoughts. Get in touch!