Please do not copy! To deter repeat offenders, IT service provider Avision explains some particularly popular blunders in software development projects.
Of course, software developers also make mistakes. Some of them are even particularly widespread. To prevent them from spreading further, IT service provider Avision explains some extremely popular blunders in development projects:
Because they are simply nice and the product owner or the specialist department want it so much, developers add a new requirement shortly before the end of the sprint. This is not a good idea, because in the end it is precisely their implementation that causes an error. This happens particularly often with very small requirements that seem unproblematic and are therefore not really taken seriously.
Another popular last-minute mistake: replacing a component shortly before the end of the development project. A bug has cropped up in a framework that we use? Then we just use a newer version of it. Unfortunately, it turns out that this one has five other bugs.
“I made a quick adjustment because it wasn’t nice.” Sounds like commendable initiative, but all too often it backfires. With such actions, developers usually do not write test cases and do not check what effects their adjustments have on the rest of the software.
Is the development project behind schedule? Then we simply switch from a conservative to an agile approach – after all, agility is a guarantee for rapid development. Unfortunately, this is not true. Agile development means meeting the needs of users better because you are more flexible. Agility ensures that you hit the target more precisely, not faster.
Another common attempt to make up for lost time is to increase the size of the team. This can even work if you increase the team from ten to eleven employees. But five new employees are too much of a good thing. They all have to be trained and the communication effort within the team increases significantly. What’s more, some processes simply take a certain amount of time – no matter how many people are working on them.
Supposed time saving for the third: In order to be faster, the team increasingly relies on test automation when testing the software. However, the situation here is similar to that of agility. Automated tests make the code better, but it is not finished any faster. As the teams have to develop the test cases in addition to the code, they do not make any faster progress overall.
“You learn from your mistakes. And you become particularly wise when you learn not only from your own mistakes, but also from the mistakes of others,” says Nadine Riederer, CEO of Avision. “Sometimes, even in development projects, you can’t avoid paying for lessons learned, but it’s only sensible to keep these expenses as low as possible.”
