The application isn't crashing. It processes orders, serves customers, passes every operational check — and it is quietly costing the company a fortune. Hugo Bramble spent seven years as CIO of Pellier Restaurant Group, a 900-location franchise operator, learning that systems don't become legacy on the day they break. They age through ordinary use: new workflows, shifting security expectations, multiplying integrations, teams reorganizing around software nobody wants to touch anymore.
Today on The Focal Point with Filiberto De La Cruz, Hugo makes the case that legacy is a business condition rather than a technical one, and that the real signal is not uptime but how expensive and frightening change has become. Listen in for how he learned to read that signal early — and how he built enough trust with franchisees and operators to act on it before the collapse.
*Hugo Bramble was serving as CIO at the time of this recording and has since stepped down.
Episode Video
About the Guest
Hugo Bramble is the former Chief Information Officer of Pellier Restaurant Group, where he inherited a point-of-sale and back-office estate that had been running successfully — and un-examined — for eighteen years. His tenure is best known internally for the "cost of change" review he introduced, a quarterly assessment that scored systems not on age or uptime but on how long a routine modification took and how many people were willing to attempt one.
Earlier in his career Hugo held technology leadership roles at Norsell Electronics, the telematics firm Vantor Fleet Systems, and beverage manufacturer Cadwell Bottling. He was also a principal at Harbourline Advisors, a technology strategy consultancy he co-owned for four years. He holds a bachelor's degree in engineering from Ardenmoor University, serves on the technology advisory board for Kestrel Point Health and the Classroom Futures Trust, and has more than 25 years of experience in corporate IT and modernization.
Transcript
When software ages
[Music] This is the Focal Point Podcast, an ongoing series where we deep dive into the meat of messy management. [Music] Whether it's technology, business, government, or entertainment, we chat about our experiences and perspectives in life [Music] and leadership. Join us as we learn about their latest insights and hopefully inspire you to have some of your own. [Music] Here's the scary part. Your application may not be broken, >> right? >> It may not be crashing. It may not be throwing alarms. It may still process orders, serve customers, generate reports, and pass all the basic operational checks >> and still be quietly costing the organization a fortune. >> Exactly. This looks like success right up until it collapses because the failure is not always visible in uptime.
It shows up in slow decisions, expensive changes, risky deployments, workarounds, teams afraid to touch the thing that supposedly runs the business. >> So, this is not really an old code problem. >> Not only that's the trap. Leaders often think legacy begins when a system becomes technically obsolete. Unsupported framework, ancient database, no tests, nobody remembers how it works. the usual suspects. >> But the article we're unpacking today makes a sharper point. Applications do not become legacy systems on a single day. They age through ordinary use. >> That feels important. Say more about that. >> Customers ask for new workflows. Security expectations change. Integrations multiply. Teams reorganize. Vendors alter their platforms. The business asks old software to carry new meaning.
And over time the question stops being does this application still run. It becomes is this application still fit for the world around it. >> That's the platform shelf life problem. >> Yes. The gap between how long software remains technically alive and how long it remains strategically useful. >> Like food in the fridge that has [Music] not visibly spoiled yet. >> Exactly. >> It's still there. The container is intact. The lights are on. but you probably should not build dinner around it. >> That's a painfully accurate modernization metaphor. >> And the bigger point is that modernization should not be a panic response. It should be a discipline for noticing when the environment has changed enough that the application is now shaping the organization more than serving it.
[Music] >> That line is the center of the whole thing because many companies do not realize the platform has become the boss. >> Right? The workflow exists because the software requires it. The approval exists because the data model cannot represent the newer reality. The manual reconciliation exists because two systems were never designed to talk. The organization starts bending around the platform. [Music] >> And that is when shelf life has expired even if the system is still running. >> The first idea in the article is almost ironic. Useful software attracts change, >> which sounds obvious, but organizations routinely behave as if change is a surprise. >> Yes, they build a system to solve a real problem. It works. People adopt it. Then suddenly other departments want to use it. Customers want adjacent workflows.
Success creates platform pressure
Leaders see that it's valuable and ask it to support more of the business. >> Success creates pressure. >> Exactly. Frederick Brooks said, "All successful software gets changed." That sentence should probably be printed above every road map review. >> Because change is not evidence that the original system failed. >> No, change is evidence that the system matters. >> Wait, that's a useful distinction. A lot of teams treat change requests as interruptions, but the article is saying they're often the natural consequence of success. >> Right? If nobody asks your software to change, maybe it is not central enough to matter. The problem is not that change arrives. The problem is whether the system was built and governed as if change would arrive. >> So the first shelf life question is not how old is this app.
It's was this app designed to keep evolving. >> Yes. Because if it wasn't, every useful extension becomes more expensive. Every new workflow stretches the architecture. Every exception becomes a permanent pathway. Every integration adds another thread tying the system to something else. >> And the system can still run while its flexibility is shrinking. [Music] >> That's the hidden cost. You do not see it as one catastrophic event. You see it as a thousand tiny increases in friction. >> A feature that should take 2 weeks takes six. >> A deployment needs three teams on standby. A simple customer request requires a data cleanup project [Music] >> or nobody can answer whether changing one field will break five downstream reports. >> And that brings us to the next idea. Change comes from outside the code.
This is the part leaders usually miss >> because when people talk about application aging, they usually talk about technical decay, outdated frameworks, unsupported dependencies, brittle architecture, missing tests. And to be clear, those matter. >> They absolutely matter. >> But the article argues that software also ages because the environment around it changes. Brooks has this broader idea that a software product is embedded in a cultural matrix of applications, users, laws, and machines. That matrix does not stand still. >> So, a system can be internally stable and externally obsolete. >> Exactly. The code may be clean by the standards of the time it was written. It may even be reliable, but the business context changed. The regulatory context changed.
Customer expectations changed, the team structure changed, the vendor ecosystem changed. >> It's like a bridge that looks stable from a distance while stress fractures are spreading underneath. >> Yes, the bridge has not fallen. Cars still cross it, but the load it carries today is not the load it was designed for. >> And that changes how leaders should assess applications. >> Right? Assessment cannot stop at code quality. You have to ask what business processes now depend on this system. Which regulations changed? Which integrations became loadbearing? Which team no longer understands the decisions baked into the architecture? >> That last one is huge. >> It is because institutional memory has a shelf life too. You can have a platform that technically still works, but the people who understand why it works are gone.
And then the software becomes less like a tool and more like an artifact. >> Exactly. People approach it carefully. Nobody wants to disturb it. They add layers around it instead of changing it directly >> which feels safe in the moment. >> But it is often how rigidity accumulates. >> That leads directly into coupling. The article says old software becomes dangerous when change in one place requires synchronized change everywhere else. >> [Music] >> Coupling turns age into rigidity. >> That is such a clean way to say it >> because age by itself is not the issue. There are old systems that are boring, stable, well understood, and perfectly fine. >> Not every old system is a crisis. >> Exactly. The danger comes when the system cannot move independently.
Measure change cost, not uptime
[Music] When a small improvement requires meetings across five teams, changes in three databases, updates to two vendor contracts, and a deployment window nobody wants to own. >> Aunt and Thomas from the pragmatic programmer said coupling is the enemy of change because it links together things that must change in parallel >> and that is the technical mechanism behind so many expensive modernization programs. The organization thinks it has old code, >> but really it has code that cannot move without dragging the whole organization with it. >> That's a painful diagnosis. >> It is, but it is also clarifying because the goal of modernization is not to make everything new. >> Wait, say more about that. >> A lot of modernization programs become novelty programs.
New cloud platform, new language, new architecture diagram, new vendor, new dashboard. But the article is saying the real goal is restored maneuverability. >> And the right things change again. >> Exactly. Sometimes that means refactoring. Sometimes it means strangling the legacy system at the edges. Sometimes it means isolating a dependency. Sometimes it means simplifying a workflow or retiring a feature no one should be maintaining anymore. >> So modernization is not about replacing old with new. It is about making change less expensive. >> Yes, the measure is not novelty. The measure is maneuverability. That should probably be written on the wall of every transformation author >> in large letters >> because otherwise you can spend millions modernizing and still preserve the same constraint.
>> Which brings us to one of the articles strongest [Music] points. Old ideas can be the real legacy. >> This is where it gets uncomfortable. >> Very uncomfortable because some legacy systems are kept alive by old technology but others are kept alive by old assumptions. what customers need, >> how teams work, >> what risk looks like, >> which reports matter, >> which approvals must exist, >> which processes are sacred, >> and the application carries those assumptions in executable form. >> That phrase is the key. Software is not just code. It is a frozen theory of how the business works >> or how the business used to work. >> Exactly. And that means replacing the platform without questioning the theory can be a very expensive act of preservation. >> You get a new system carrying yesterday's business logic.
>> A new house built around the old plumbing >> or a scaffolding that becomes a ceiling. >> That's a good one. >> Because scaffolding is supposed to help you build, but if you never remove it, eventually it defines what can be built. >> That is what happens with legacy assumptions. The workaround becomes the workflow. The exception becomes the process. The old approval path becomes how we do things here. >> So before replacing a platform, leaders should ask which beliefs the platform preserves. >> Yes. Does the workflows still match how work should happen? Does the data model still reflect the business? Does the permission structure still match accountability? Do the reports still drive decisions that matter? Because migrating old assumptions into new infrastructure is not modernization. >> It is preservation with a larger budget.
Modernize for maneuverability
>> That sentence hurts because it is true. >> And it explains why some transformations feel successful technically but disappointing organizationally. >> The migration completes. >> The vendor goes live. >> The dashboard turns green. >> But users still work around the system. Teams still wait on each other. Engineers still fear [Music] changes. Leaders still can't get the answers they need. >> Right. Because the dashboard only shows the smoke, not the wiring inside the walls. >> Exactly. And if [Music] the wiring is still faulty, the smoke detector isn't the fix. >> The article then moves into the need for continuous improvement, >> which is probably the least glamorous and most important idea. Applications decay when maintenance becomes a periodic rescue mission. >> That is so common.
Teams defer small improvements because the system is not painful enough yet. Dependencies can wait. Test coverage can wait. Documentation can wait. Deployment cleanup can wait. Unused features can wait >> until suddenly everything cannot wait. >> And by then the work is larger, riskier, and politically harder. The Phoenix project line fits here. If you're not improving, entropy guarantees you're actually getting worse. >> That's the thing about software shelf life. Decline doesn't require active neglect. The world just has to keep moving while the system doesn't. >> That's a really important leadership point. >> Yes. Because leaders sometimes think we have not touched that system much so it should be stable. >> But untouched is not the same as healthy. Exactly. In a changing environment, untouched can mean drifting out of fit.
>> Like a dashboard that shows fever but not the disease. By the time the fever is obvious, the underlying issue has been developing for a while. >> That is why renewal has to be funded as part of normal operation, not as hero work, [Music] not as a special rescue program every 5 years. Normal operation. >> So what does that look like in practice? paying down coupling, updating dependencies, removing unused features, improving deployment paths, keeping knowledge distributed, making sure more than one person understands critical decisions, watching for workarounds, and treating system fitness as an ongoing responsibility. >> A drum beat, not a siren. >> Exactly. [Music] A drum beat keeps the marching group together. A siren means something has already gone wrong. And most organizations wait for the siren.
>> They do because routine renewal is hard to defend when everything appears fine >> until change gets expensive. >> Then modernization becomes urgent, highly visible and politically complicated. >> Which brings us to the final question the article asked. What is your application still [Music] fit for? >> That question is better than is this system old? much better >> because not every old system should be replaced. Some should be protected. Some should be simplified. Some should be kept boring. Some should be retired. Some should be gradually decomposed. >> The right answer depends on the role the system plays and the cost of keeping it in its current shape. >> Exactly. Leaders need to distinguish running from fit. >> So let's make this practical. [Music] What questions should a leader ask inside their own organization?
Questions before replacement
>> Start with this. Does the application still support the business model it now serves? >> Not the business model from 5 years ago, >> right? The current [Music] one, the one customers are actually responding to, the one teams are actually operating. >> Second, can teams change it safely? >> And safely means technically and organizationally. Can engineers test it, deploy it, understand the blast radius, get decisions made without a month of coordination? >> Third, are users working around it? >> That is often the clearest signal. Spreadsheets, side databases, manual approvals, duplicate entry, slack messages that replace system workflow. >> Workarounds are not just inefficiency. [Music] They're user generated evidence that the platform no longer fits. >> Exactly. Fourth, are security and compliance teams compensating for it?
>> That one matters because compensation can look like control. Extra reviews, manual checks, restricted access, special procedures, but sometimes those controls exist because the platform cannot express the right model of risk anymore. >> Fifth, are engineers afraid of touching it? >> Fear is data. >> That's a useful leadership phrase. If teams avoid a system, route around it, or only assign the most senior person to make changes, that tells you something. Maybe the system is too coupled, maybe knowledge is too concentrated, maybe deployment is too risky, maybe the architecture no longer matches the business. >> And the final question might be, is this platform giving the organization room to move? >> That is the heart of it. [Music] A healthy platform creates options. An aging platform removes them.
>> So modernization begins with honesty about age >> and honesty means not hiding behind uptime >> because uptime can tell you the system is alive >> but it cannot tell you whether the system is still fit. >> That echoes the opening. The scary part is that the application may not be broken. It may still be running, >> still producing reports, >> still serving customers, >> still passing the basic checks, [Music] >> and still quietly shaping the organization around yesterday's assumptions. >> By the time the dashboard turns red, the real failure may have already happened. >> The wiring inside the walls has been degrading. The bridge has been accumulating stress factors. The scaffold has become the ceiling. So the leadership challenge is not just to ask does it work.
>> It is to ask can it keep changing >> because software that cannot change eventually changes the organization instead [Music] >> and that may be the clearest sign that its shelf life has expired. >> Not when it stops running >> but when it stops giving the business room to move. >> That's the warning sign. >> And there may be no warning sign louder than that. Thank you for tuning in to this episode of The Focal Point. Be sure to subscribe on your favorite platform. [Music] I am your host, Filiberto De La Cruz. Until next time, God bless you and yours and everyone. [Music] Heat. Heat. [Music] [Music] >> [Music]
