When C++ developer Roger Swann took over the development of a sensor-testing software, the engineer who wrote it was no longer available to explain any of it\u2014a situation that has been happening more and more frequently when inheriting older codebases.<\/p>\n
The original author was a C programmer, not a C++ or object-oriented specialist. He’d built the first iteration to address one practical question: we need to automatically test this sensor, how do we do it?<\/em> His approach worked.<\/p>\n But as the customer grew from a single sensor into a whole range of them, the software grew too, one feature request at a time. There was no time in between fast dev cycles to plan a design. It ran on Microsoft Visual C++ 6 with MFC, with an MS Access database holding every test result the company had ever recorded.<\/p>\n Roger, who is now director at Cigol Controls<\/a>, came in at arguably the worst possible moment for a handover. The UK-based electronics engineering and manufacturing company\u00a0was moving to a much larger site with a much bigger sensor-testing system, so the software needed major changes. At the same time, the original developer had fallen sick and was no longer available.<\/p>\n There was not even an opportunity, as Roger puts it, “to answer questions on ‘how does this function work?'”<\/p>\n There was also a deadline. Without working software, the customer can’t test sensors, and if they can’t test sensors, they can’t ship them.<\/p>\n “I almost didn’t take the job on,” Roger says.<\/p>\n The word gets thrown around, so it helps to be specific about what Roger walked into.<\/p>\n “Everything was done with large numbers of ‘case’ statements or ‘if \/ else’ statements,” he says. “For any particular sensor type it was unbelievably painful to follow through exactly what the program flow was.” The logic that drove the test hardware (the digital inputs and outputs he now had to change for the new site) was completely tangled into the operating code. You couldn’t touch one without reaching into the other.<\/p>\n The coupling had teeth. “Changes that affected one type of sensor could (and did) accidentally have an unwanted change to the way other sensor types were tested.” Fixing a problem for one product quietly created one for another.<\/p>\n On top of that, the customer was reporting a steady stream of bugs and had built up their own cumbersome workarounds. The software needed regular restarts. Roger could see the day-to-day users getting close to losing confidence in the whole system.<\/p>\n An even bigger problem was that almost none of it could be tested off-site. There was no simulation of the sensor hardware and no unit tests, so running the code meant you had to be physically in the factory, interrupting operations and requiring development engineers to do it. There wasn’t even a Windows installer. A build compiled as “release” would run on the development PC but fail on the customer’s target machines (for reasons Roger never fully got to the bottom of even now).<\/p>\n Roger was a new supplier trying to make a good impression, on a deadline, with a codebase he didn’t write and couldn’t fully test. So he didn’t start with a full and grandiose rewrite.<\/p>\n He started with minor feature changes. Small, low-complexity work that, in his words, “in effect paid for me to get to know the code.” It also showed him how hard the move to the new factory was going to be. He was still in Visual C++ 6 at this stage. He began pulling the I\/O-related code (the part that talks to the test hardware) out of the tangle, so he could modify it for the new site without disturbing everything around it.<\/p>\n His method was what experienced engineers eventually converge on when working on legacy code. “With spaghetti code you do have to try to make as small a change as possible and then re-test,” he says, “even if re-testing means lengthy time on site and inconveniencing the customer.” One change, one test, repeat, even when a single test cost him a trip to the factory.<\/p>\n That discipline is also what earned him the room to do more. Only after he’d delivered the factory move and the software was working did he feel the customer trusted him enough to take on the bigger job.<\/p>\n The bigger job was a move to Embarcadero C++ Builder<\/a> and VCL. The central change was structural: a class hierarchy for the different sensor types.<\/p>\n Before, a change to one sensor type could reach into another. After the structural shift, each sensor type is its own class and new ones drop in without disturbing the rest.<\/p><\/div>\n That one decision fixed the problem that had made the old code so dangerous. “I quickly got to the point where when a new sensor type was introduced it could be done without unwanted (disastrous) side effects for other sensor types,” Roger says. The object-oriented structure made the system far more stable, in his words “now regarded as completely stable.”<\/p>\n The rest of the modernization followed from there. He built a way to simulate specific sensor types, so the software could finally be run in full on a development PC instead of only in the factory. He added unit tests, especially around the low-level code, where he finds it easier to debug against a test than by hand. The bonus is that the tricky code stays checked from then on. He added a proper Windows installer.<\/p>\n Later, when years of accumulated test results pushed the MS Access database past its limits, he migrated the whole thing to PostgreSQL. Because the data layer already went through FireDAC by then, even that went smoothly.<\/p>\n None of this was a from-scratch rewrite. It was a running system carried forward in pieces, each one replaced only once he understood it well enough to replace it safely.<\/p>\n Ask Roger what advice he’d share with another engineer inheriting a mess like this and the advice is pretty straightforward.<\/p>\n “Don’t think you can re-write completely from scratch. Rather, work with little sections of code and migrate bit-by-bit. Add unit testing or other forms of higher level simulation testing as you go along. By migrating (rather than completely re-writing) you keep the small (but important) bug fixes that exist without you seeing them in the code base.”<\/p>\n The loop never changed \u2014 small change, then test, then repeat.<\/em> What changed is that testing moved from slow factory visits to simulation and unit tests.<\/p><\/div>\n Don’t underestimate the invisible bug fixes that you inherit. A legacy codebase collects tiny corrections nobody documented: e.g. a guard against an input that only appears at random, a workaround added for one customer’s hardware.<\/p>\n Rewrite from scratch and you throw all of them away without ever knowing they were there. It’s the same argument Joel Spolsky made in Things You Should Never Do<\/em><\/a>, which we lean on in the survival guide that spurred this discussion<\/a>. Roger just arrived at it the hard way, on a real system, with a more real-world pressure (a literal factory).<\/p>\n He also has a test for whether someone is any good at this. “You can tell a good software engineer,” he says. “Their first question is always ‘how am I going to test this?’ rather than the more common ‘how am I going to write this?'”<\/p>\n For most of the grind, Roger managed with the limited Visual C++ 6 IDE. The heavy lifting was surgical methodology and patience more than tooling.<\/p>\n More recently, working in C++ Builder, he’s been introduced to the Whole Tomato tooling built into that IDE: the refactoring (renaming, mostly), find references, and jump-to-definition. On a codebase where following the program flow was the original nightmare, being able to jump straight from a call to its definition, or find every place a function is used, is exactly the kind of help that pays off. “I’d love to see more,” he adds, which we’ll take.<\/p>\n Roger’s story is specific to sensor-testing rigs, but the shape of it is not. Someone before you built something that worked, under pressure, without a plan. Now it’s yours, and the person who understood it isn’t around to ask.<\/p>\n The way through is the way Roger went: small, tested, reversible changes; a structure you introduce gradually; and a bias toward migrating what exists over rewriting it from nothing. If you want the longer version of that playbook, it’s the whole argument of our field guide, Inheriting a Legacy C++ Codebase<\/em><\/a>. It walks through the first 90 days, from surviving the hectic initial phase to shipping changes without drama.<\/p>\n And when the codebase itself is the thing slowing you down, when jumping to a definition or finding every caller has become a stall instead of a reflex, that’s what Visual Assist does for Visual Studio. It’s the Visual Studio counterpart to the Whole Tomato tooling Roger leans on in C++ Builder, built for the same large, tangled C++ that makes inheriting a codebase hard in the first place.<\/p>\nWhat “spaghetti” actually meant<\/h2>\n
The first move was small on purpose<\/h2>\n
Migrate, don’t rewrite<\/h2>\n
![\"Before-and-after](\"https:\/\/i0.wp.com\/www.wholetomato.com\/blog\/wp-content\/uploads\/2026\/08\/Figure-1.png?resize=1024%2C576&ssl=1\")
<\/a>The discipline underneath all of it<\/h2>\n
![\"A](\"https:\/\/i0.wp.com\/www.wholetomato.com\/blog\/wp-content\/uploads\/2026\/08\/Figure-2.png?resize=1024%2C683&ssl=1\")
<\/a>The tools that earned their keep<\/h2>\n
If you’re the one who just inherited the mess<\/h2>\n