The Number One Reason For Subpar Software Revealed

by | Jul 9, 2025

B O N C O D E   B L O G

Not long ago, I was called in by a company experiencing significant growing pains. On paper, they looked like a healthy scale-up: 12 years old, solid market presence, and a newly appointed CEO with a strong commercial vision. Brought in to drive the next wave of growth, he had an ambitious product roadmap. So what was the issue? The tech team couldn’t deliver it.

– By Jan Willem Klerkx, CEO, BonCode –

Start with the right ambition

What made this assignment unique was the CEO’s request: “Don’t just assess our technical quality, find out the root cause why it’s suboptimal.” That, I thought, was the right ambition.

The CTO, a founder and long-time engineer, was frank from the outset. “We’re buried in maintenance and bug fixing,” he said. “We’ve grown fast, we’ve taken shortcuts to meet customers expectations, and we’ve accumulated too much technical debt. We brought in new staff, but they need a long time to find their way. We simply don’t have the capacity.” It wasn’t easy for the CEO to hear, but he respected the honesty. Too often, people avoid these conversations until it’s too late.

Our response? A phased approach. We began with code analysis and confirmed the CTO’s suspicions: high technical debt, poor maintainability. But it got even more interesting when we looked at it on an architectural level. Over the past five years, there had been several attempts to introduce new architectures. None had stuck. Why?

Architectural drift and the role of governance

The pattern was clear: software architects would design ambitious new systems, but they lacked the governance to see them through. Business deadlines took priority, developers cut corners, and over time, architectural integrity eroded. The architects moved on, and the cycle repeated itself.

When interviewed, engineers admitted skipping steps to satisfy commercial demands. No malice, just pressure. And then came the real turning point: the CTO told me he never wanted to be a CTO. He liked building things, not managing people or enforcing architecture. “I don’t like correcting my fellow staff members, even if there’s a need to do so”. He had, quite understandably, defaulted to what he was good at: coding, not leading.  This, I found, was impressive. How many people would feel safe enough to state this? Clearly, the CEO had been very successful in creating a corporate culture where important things could be shared without fear.  

The simple, structural fix

Once this was on the table, the resolution was simple (in hindsight). The CTO took a step back from management and focused on leading a refactoring effort, something he was exceptionally skilled at. A new technical manager was brought in, someone who liked managing and could enforce architectural discipline. Within two months, the codebase was stable enough to begin implementing the CEO’s roadmap. The first new modules were on the market already. 

Technical issues? What technical issues?

This story illustrates something I’ve seen time and time again: technical issues are often symptoms of deeper organizational problems. So instead of just asking “What’s wrong with our software code?” leaders also need to ask these five questions:

  1. Are responsibilities for software clearly defined and understood?
  2. Do people feel safe to speak up when something isn’t working?
  3. Are people expected to lead in areas where they’re not comfortable?
  4. Is technical governance overridden by business urgency?
  5. Have we outgrown our startup ways without updating our structure?

When organizations create the right environment, where structure, safety, and responsibility align, technical quality improves as a natural outcome. As companies scale, the demands on their systems change. But just as importantly, so do the demands on their people. 

You can’t grow a company on founder instinct forever. At some point, you need structure, governance, and clarity about who’s doing what and why. So the next time you’re grappling with technical debt, ask yourself this: are you fixing code, or are you ignoring an organizational blind spot?

Let’s talk about code quality and how we can help you keep it under control. Contact us.

You may be interested in this:

How software managers benefit from benchmarking

How software managers benefit from benchmarking

BonCode doesn’t just provide numbers around software quality, it provides clarity. We measure hundreds of metrics and roll them up into a single maintainability score. That score helps managers see where progress is being made and where risk lies, across their...

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.