Why is software development so slow?

January 17, 2022

Why is software development so slow?

Why does it take too long to implement simple changes?

John: “How long will it take you to implement this change?”

Bob: “I’m not sure. I have to analyze it. It’s complex. Maybe 10 days… but could also be more complex if we run into complications.”

John: “10 days?! But it’s so simple! How could it possibly take so long? Shouldn’t it take just a few hours?”

Bob: “Well the problem is that it affects multiple parts of the system. I’d also need to speak with Peter and Sue regarding their modules. We have to analyze the code, this is a complex change, and we’ll have to debug a lot to make sure it works. After that, Jill will also need to update the test procedures, and re-run a lot of regression tests.”

John was really frustrated by now. Bob’s estimate seemed too high. How could a really simple change take so long? Sometimes, he felt he was losing trust in the development team. He felt like the developers were fast at the beginning, rolling out functionalities blazing fast, but then it got slower… and slower… He called up the customer and told him the updated date.

Time passed. After several days of development… They waited for Jill to finish QA regression testing. Jill found several critical regression bugs impacting core functionalities.

John was getting impatient. They were really close to the release date, and now they’re finding critical bugs at the last minute? Why weren’t the developers more careful? Why can’t they just implement new functionality and not break what’s working?

Bob, Peter, and Sue set to solve the regression bugs. Then waited for Jill to re-do regression testing. But then she found additional regression bugs. And the cycles repeated. By the time the initial and the new regression bugs were solved, another 10 days had passed.

After having to apologize to the customer again, John was frustrated that it ended up taking 20 days, when the estimate was 10 days. And the even more frustrating part was that 50% of that time was spent fixing things that the developers broke themselves.

Then the production launch. Then John got a call from their biggest customer, Martin.

Martin: “The system has stopped working! Our business is losing thousands as we speak!”

John got all the team together and told them what it meant. They knew what it meant since Martin was their one biggest customer. It was another daunting marathon bug fixing session. And then waiting for the QA regression testing. Rinse and repeat. It was getting late. Then they started making even more mistakes.

But finally, after the heroism, it worked. They deployed to production.

EPILOGUE

This is a common story – changes take too long, too many bugs. If the team had adopted CI/CD & TDD then they would have been able to implement changes much faster, much more safely…

Optivem Group LLC 30 North Gould Street Sheridan, WY 82801 United States

Optivem DOO, MB 21609722, PIB 112111924, Heroja Maričića 93, Kraljevo 36000, Serbia

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.