Unmaintainable software? You can’t be agile.
👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. To get these articles in your inbox every week, subscribe:
What’s the #1 cost in software development? The cost of software maintenance.
I’m excited to open the Tech Excellence Conference 2024 by drilling into Software Maintenance Costs.
The pain of Software Maintenance
Based on years working in software development, it was a nightmare to maintain the existing codebases. Often there were no automated tests. Sometimes it took hours just to try to figure out what the code was doing, do a lot of analysis to try to figure out how to make the change without messing up existing behavior, make the change, and then *hope* nothing was broken. There weren’t any tests to protect me.
It was an analysis-hope-driven kind of development. Very stressful.
I came to realize that software maintenance has a high cost because:
No tests or poor tests → we had no protection when making a change
Unreadable code → it was hard to make the change itself
As a Senior Developer & Tech Lead, my main focus shifted towards setting up the right automated testing strategy & architecture to minimize maintenance costs.
Maintenance = #1 cost in software development
The biggest cost in software development is software maintenance. With bad technical practices, software maintenance costs sky-rocket, they become unmanageable, and eventually, like an avalanche, they destroy successful products.
We’re fire-fighting, yet talking about AI?!
We’re in 2024, talking about AI, yet we’re stuck with primitive technical practices. Software is getting increasingly complex, and we’re spending most of our development time just trying to keep the product afloat with daily fire-fighting.
Many of these problems were solved over two decades ago - with Extreme Programming (XP), including notable practices such as TDD - yet they are still not mainstream. The mainstream development approach still remains the Big Ball of Mud.
Automated Testing is missing in many teams
For many companies, Automated Testing is non-existent or poor, with key reliance on Manual QA Engineers and some automated E2E tests, often practicing the Inverted Test Pyramid. Developers skip writing Unit Tests, and they do so when forced by engineering managers to achieve 80% code coverage thresholds.
Even then, those tests don’t protect them against regression bugs. This test approach is expensive to maintain, yet is almost worthless in regression bug protection. With this absence in the Automated Testing skillset, we’re far, far away from TDD.
Winning the 100m race or the marathon?
The quick-and-dirty approach is fine at the beginning. We appear to be fast, in the 100m race. But we lose the marathon, because quick-and-dirty development is extremely expensive over the long run, as the cost of software maintenance is the biggest in the total cost of software development.
Most of the development time is spent on bug fixing, fewer and fewer features are released, and eventually, no amount of Manual QA Testing can keep up… we start releasing more and more regression bugs to customers, causing customers to lose trust in our product and switch to competitors… causing us revenue loss, brand reputation loss, sometimes even lawsuits, and in the worst case - bankruptcy.
Unmaintainable software? You can’t be agile.
With bad practices, software maintenance costs are too high. Responding to change is too expensive. We can’t deliver frequently. We can’t keep up with changing business demands. That's why technical excellence is essential for agility.
Outline of the session:
Bad-quality software is expensive to maintain
Developers are wasting a lot of time debugging
Many companies have a poor test automation strategy
It is impossible to refactor to clean code with an inadequate test suite
Low-quality software development is unsustainable
TDD & Continuous Delivery are the foundations for maintainable software
📅 Friday, 22nd November 2024
About Valentina Jemuović
Valentina Jemuović is the Technical Coach & Founder at Optivem. She works with Engineering Leaders to improve quality by coaching development teams in TDD, Hexagonal Architecture & Clean Architecture. She helps teams strive toward Zero Defect Software and accelerate delivery to release reliable software faster. She worked with clients across Europe and North America, with a special focus on Industrial Automation, Finance and Logistics.
Previously, Valentina had extensive hands-on experience in software development - as a Senior Software Developer, Tech Lead, Software Architect, and Solutions Architect. She graduated with a dual degree from the University of Sydney, majoring in Computer Science, Advanced Mathematics, and Finance.
Optivem Journal: journal.optivem.com
LinkedIn: linkedin.com/in/valentinajemuovic
Twitter: x.com/valentinajemuov
YouTube: youtube.com/@valentinajemuovic
GitHub: github.com/valentinajemuovic
Instagram: instagram.com/valentinajemuovic
Optivem: optivem.com
Want to apply TDD in practice?
You tried TDD, but it didn’t work. That's why I'm going to help you practice TDD step-by-step. Apply TDD on a sandbox project. Access TDD in Legacy Code.
The tools have advanced, while the technical practices have stayed the same.
"The mainstream development approach still remains the Big Ball of Mud."
Isn't that the truth! In many ways we've gone backwards from where we were 25 years ago :(