Any programmer can tell you that refactoring is huge headache, but despite thousands of hours collaborating with development teams, I used to spend little time thinking about technical debt.
As a long-time product leader – with more than 15 years serving over a dozen institutions working on countless products – I should have known better.
Sure, I knew that refactoring projects were taking resources from other initiatives. I knew the customer satisfaction impact of slow or buggy products. And I certainly knew how much my architect and developer friends hated working on someone else’s spaghetti code.
Still, refactoring felt like a developer problem. However, when I saw what Sema was doing it was immediately clear to me how speeding up and improving refactoring projects has benefits that extend far beyond the development team.
First and foremost, every product leader knows the pain of having your product roadmap decimated by refactoring projects. Interviews with development leaders reveale that maintenance work consumes anywhere from 30% to 70% of development budgets.
70%. I wouldn't have believed it if I hadn't lived it.
I’ve been in numerous planning sessions over the years where the first thing we did was pull out half our Development resources to work on maintenance issues: tech debt, performance enhancements, and bug fixes. There isn’t much room to innovate after that, and it’s hard to get ahead of your competitors when you aren't releasing new products or features. Your customers aren't going to love you for "it's not broken anymore." And nobody has ever purchased something called "Same Product, Working Properly.”
Another reason for my excitement is data, data, data. Product management has increasingly shifted to data-driven decision making. We conduct surveys, analyze win/loss data and NPS scores, and hang over our customers' shoulders watching them use our products. We make decisions based on specific goals, then measure success against defined metrics.
But when it comes to maintenance, Development leadership is often in the unenviable position of proving the impact of technical debt and justifying the time it will take to refactor the code. Even worse, developers are often untangling a system built by someone else, and until they start working, the true scope of the project is genuinely unknown.
I joined Sema because, more than any other company or solution I’ve seen, they are leading the way in analyzing, quantifying, and - most importantly - helping to fix code problems.
Sema Detect and Sema Refactor are giving technical teams greater visibility into technical debt as well as powerful new tools to fix it. Sema makes refactoring projects shorter, more predictable and more measurable, reducing the maintenance burden and budget.
Better software maintenance means development teams and product teams are united on what really matters: building the future.
Technical debt is everyone's problem, which why as a product leader, I'm excited to be part of the solution. Contact us to find out how you can be part of it too.
This part 1 of our series on the value of Sema to different teams. In future posts, we'll talk about how Sema benefits CTOs, Architects and Developers.