Classic mistakes in software engineering

Let's talk about well known, ineffective development practices. These practices, when followed, tend to lead to predictably bad results.

People
We're going to start with mistakes involving people. And notice that there is a long list. So I'm going to discuss just a few of those mistakes.

Heroics: This refers to too much emphasis on can do attitudes, so this idea that one person by himself or by herself can do everything and can make the difference in the whole project. And unfortunately, this encourages extreme risk taking and discourages cooperation, which is plain bad for the project. For example, it might force people not to report schedule slips. It might force people to take on on too much responsibility. And normally, and I saw it happen many times, the final result is a failure. So what you want when you're developing a larger project, is actually to apply soft engineering principles. Have teams, have team work, and have cooperation among the different team members, without pointing too much on single individuals.

Not create the right working environment: We all like to work in nice environments. And there is strong evidence that the working environments can play a big role in productivity. There is evidence that productivity increases when the workplace is nice, quiet, warm, and welcoming.

Poor people management: For example, lack of leaderships, or leadership that is exercised using the wrong means in the wrong way, which can lead to very unhappy personnel and therefore, low productivity, or even people leaving teams. Another classic example of poor management is adding people to a project that is behind schedule, which never works. Why it doesn't work? Because these new people need to be brought up to speed, and that causes further delays rather than improving the situation with the project schedule.

Process
Another type of classic mistakes are process-related mistakes. And also in this case, these kind of mistakes can be due to many reasons.

Scheduling issues: which are due to the fact of being unable to come up with a realistic schedule. So to have an overly optimistic schedule. And this can be because we underestimate the effort involved in different parts of the project. Because we overestimate the ability of the people involved. Because we overestimate the importance, for example, of the use of tools. But no matter what the reason is, the result is typically that the projects end up being late, which is a very common situation.

Planning issues: planning is a fundamental factor in software processes and in software development. Mistakes in planning, such as insufficient planning or abandoning planning due to pressure, usually lead inexorably to failure.

Unforeseen failures: Such as failures on the constructor's end, for example, that might lead to low quality or late deliverables, which ultimately affects the downstream activities.

Product
The third category of mistakes that I want to mention is product-related mistakes.

Gold plating of requirements: It's very common for projects to have more requirements than they actually need. For example, marketing might want to add more features than the ones that are actually needed by the users. And of course having more requirements lengthens the project's schedule in a totally unnecessary way.

Feature creep: consists in adding more and more features to a product that were not initially planned and are not really needed in most cases. And here there is evidence that the average project experiences about a 25% growth in the number of features over its lifetime which can clearly highly effect The project schedule.

Research vs. Development: If you're working on a project that strains the limits of computer science. For example, because you need to develop new algorithms for the project, or you have to use new techniques. Then that project might be more research than actual development. And therefore, it should be managed accordingly. For example, by taking into account that you will have a highly unpredictable schedule.

Technology
Silver-bullet syndrome: refers to situations in which there is too much reliance on the advertised benefits of some previously unused technology. For example, a new technology. And the problem here is that we cannot expect technology alone to solve our software development issues. So we should not rely too much on technology alone.

Switch or add tools in the middle of a project: sometimes it can make sense to upgrade a tool, but introducing new tools, which can have a steep learning curve, has almost always negative effects.

Lack of an automated version control system: Manual and ad hoc solutions are just not an option. It is way too easy to make mistakes, use out of date versions, be unable to find a previous working version, and so on.