Three myths about software development
Many managers think that formal requirements assessments are unnecessary, that development projects can be accelerated simply by putting pressure on the developers, or that if a small team of programmers cannot complete development in time, it is enough to add more people to the team to speed it up. Here I explain why these myths are false and can also lead to total project failure.
Business administration is usually carried out by very talented people who have known how to position a brand and lead a team, without the need for the theoretical tools of formal training, such as that provided by an MBA. Much less specialized training in computer or technology management. As a result, they act primarily on instinct and a kind of “common sense” that makes them think that good practices that work in one sector are transferable to another as if it were a matter of copy and paste.
Those of us with more than two decades of experience in IT project management know very well that this is not the case. Software development is a very different activity from others, and good practices in this area are often far from what works in other industries. In particular, there are three widespread myths that commit this mistake and that can make a development project fail, even before it is finished. Here I analyze them indicating why one should not fall into these management errors.
UML and formal analysis
Many managers think that doing a formal requirements analysis is a waste of time that contributes nothing and that hinders and slows down the start of the “real work”, which consists of writing the code and populating databases. The truth could not be more different.
The main reason why a formal specification — for example, in UML — is useful and necessary, is not of a computer science nature as such, but solely aims at safeguarding a legal and juridical aspect: a formal specification makes it possible to delimit the limits of development, in a clear and precise way, in a way that a written contract can never achieve. In other words: the client can always interpret a contract differently from the developer and demand compliance with deliverables — or details of the deliverables — that was not established in the contract. A formal survey, on the other hand, dispels this ambiguity, since it allows the scope of the project and its level of detail to be precisely defined.
Another reason for making a formal survey is that without it, serious errors can be made in the development itself. The example that — in my opinion — best illustrates this is the structure of a database. A common mistake in development projects is to design “databases” to serve the purposes of a single application. This is a fatal error, since the very concept of “database” refers to a set of files that allow storing, in a structured way, all the data that a set of several applications use. That is why it is called “base”, because it is at the base, on the lower level, of several developments, not just one.
So how can you guess what data requirements might arise in the future? We’d need a crystal ball, wouldn’t we? The answer is that there is a proven methodology, well known to experts, called “data modelling” that allows you to do it, in a certain way. Data modelling should always begin with a set of interviews with the customer, in which he is not consulted about the specific and precise requirements of the application to be developed, but about the very nature of the data. From this conceptual model, the structure of the database can be derived (and normalized), to give guarantees that it will truly serve as a “base” for any application that is built later, even if its specific requirements are not yet apparent.
Carrot and stick
Another common misconception in IT project management is the common belief that you can speed up development by simply applying the “carrot and stick” philosophy, especially by putting pressure on developers to speed up their work. This is a big mistake because software development is more of an art than a technique. An average developer is a person who loves what he does and is naturally motivated by the challenges that the activity provides. This motivation is so strong that it is not uncommon for a programmer to stay up late at night, working on a piece of code to complete it, and just for the pleasure of achieving that goal.
When a project manager puts pressure on a developer and rushes him, the only thing he gets is that the “artist” becomes a pragmatic being, who will be willing to hand over any piece of work, without it being finished, as long as the deadlines are met. Thus, the manager will be very happy that the software was finished in record time, unable to realize that the shortcomings and even errors that may contain the application will discredit him — in the long term — to the customer and may even trigger an ordeal of legal problems and the need to make expensive maintenance, without there being financial flows to pay for them.
The Mongolian Horde
Very much along the lines of “carrot and stick”, the myth of the Mongolian horde consists of the infamous belief that, if development is behind schedule, it is enough to add programmers to the team to speed it up. This may seem like common sense because there are many activities where a horde can act faster than a small group, but in highly specialized jobs, where it is necessary to go into very specific details and soak them up, to bring them to fruition, as is also the case with surgery, the design of a spaceship, the management of a nuclear plant and the peer review of an academic paper, adding more people to the team, instead of speeding up the work, it does just the opposite, slowing it down.
The new member has to be inducted for a long time before he or she is in a position to contribute something useful. Besides, his or her point of view and vision of things may be different from that of the original team. The latter is particularly relevant when the new member is a kind of crack, with a lot of experience and skills, so incorporating a “top programmer” into a development team that is behind schedule is the worst decision you could make.
Conclusions
It is important for the managers of companies dedicated to IT and technological development to be aware of these three myths, so they can avoid them, especially when it comes to startups. Such mistakes can even make a startup go bankrupt, in the blink of an eye, as “debut and farewell”.
