ROI Case File No.447 'The Code Left Behind by a Designer Thirty Years Gone'
The Code Left Behind by a Designer Thirty Years Gone
Chapter 1: The System That Won't Export CSV
"When we try to export a CSV, we get an error and it stops. It's been that way for thirty years."
John Smith, IT Manager at the overseas headquarters of Globex Corporation, said this calmly over a video call. But the weight of the words was unmistakable. For thirty years, no one had resolved the problem.
"Was the sales management system built from scratch?" I asked.
"In-house engineers built it from zero back then. Since then, we've customized it repeatedly as the business changed. But the original designer left long ago, and today no one understands the full codebase."
"You mentioned a new business starting in the autumn?" Gemini confirmed.
"Yes. A contract with a new trading partner requires us to submit monthly sales data in CSV format. The current system can't do that. We tried patching it, but no one — not even the development firm — can tell what will break if they touch anything."
"What's the situation with your internal staff?" Claude asked.
"Two employees are reaching mandatory retirement age this year. In practice, they're the only ones who know how to operate this system. The knowledge concentration is past its limit. Beyond the autumn problem, this has become a decision we can no longer avoid."
The problem was not simply "CSV won't export." Multiple issues had accumulated in layers across thirty years of time.
Chapter 2: Dissecting the Problem Across Six Coordinates
"This case calls for the 6D-MATRIX."
Gemini arranged six boxes on the whiteboard — the intersection of a time axis (present, past, future) and a perspective axis (WHY, HOW, WHAT).
"The 6D-MATRIX," I began, "is a framework for observing a problem from six dimensions simultaneously. Most of the time, we try to address problems by looking only at present symptoms. But behind those symptoms lies historical context, and letting the problem persist creates future risk. Layered on top are questions of why it's happening, how to solve it, and what needs to change. Filling all six coordinates reveals the complete picture of the problem for the first time."
"Let's fill them in one by one," Claude prompted.
[Present × WHAT: What is happening now?]
"CSV export functionality either doesn't exist or exists but doesn't work. Monthly data submission requires manual re-entry or is not possible at all. The workload on staff is high and prone to errors."
[Past × WHY: How did it come to this?]
"At the time of original development thirty years ago, CSV export didn't exist as a business requirement. Every subsequent customization addressed the business needs of that moment. Each time a person who understood the system's architecture left, knowledge disappeared — leaving the next owner no choice but to maintain the status quo."
"This is the thirty-year structure," I emphasized. "No one intended to let it deteriorate. In an organization where knowledge leaves with the person, systems become 'untouchable' over time."
[Future × HOW: What happens if nothing changes?]
"Let me run a risk scenario analysis in ROI Polygraph," Gemini said, opening the tool.
The inputs — the two impending retirements, the new business launch, the unreadable state of the current system — produced a sobering risk assessment. If no action is taken within the year, there is a high probability of being unable to fulfill the new trading partner contract, and the surfacing of the knowledge concentration risk could lead to operational stoppage.
"The Future × HOW axis," Claude continued, "is a binary: incremental customization, or full replacement. Customization looks cheaper in the short term. But adding modifications to a system no one fully understands means stacking risk on top of risk."
[The intersection of three axes: The courage to change WHAT]
"Filling all six boxes," I summarized, "narrows the answer to one: full replacement. But —" I continued, "the most important design philosophy shift in that replacement is 'making the business adapt to the system.'"
"What do you mean?" John asked.
"Thirty years of adapting the system to the business through customization is what created this situation. With the next system, reverse that completely. Maximize the use of standard package features and change the business process side. By minimizing customization, you create a system anyone can operate thirty years from now."
Chapter 3: Counting Down to Autumn
John took notes, then said quietly: "It was surprising to see thirty years of problems fit into six boxes. Something that looked complex becomes simple when it's organized."
"The effect of the 6D-MATRIX," Gemini replied, "is being able to distinguish 'what to solve right now' from 'what to change over time.' What's needed by autumn is only the CSV export function. There may be a way to handle that with a temporary bridging tool before the full migration."
"In other words," I made it concrete, "a two-phase solution. Phase one — by autumn, implement CSV export only as a stopgap. Build an external tool that extracts data from the existing system and converts it to CSV. This fulfills the new trading partner contract. Phase two — complete full replacement within the year. Begin data migration to the new system and documentation of handover knowledge in parallel, before the two retiring employees leave."
"The importance of these two phases," Claude added, "is that separating the autumn problem from the next-year problem lets each be handled at its optimal pace. Combining them into one project risks letting the autumn deadline compromise the quality of the long-term architecture."
John nodded firmly. "Next week, I'm showing the 6D-MATRIX to the two internal staff members. We need to start converting their knowledge into documents now."
Chapter 4: To the Designer Thirty Years Hence
After the call ended, Claude said quietly: "The designer thirty years ago didn't build a bad system. They did their best for that era. They just didn't design the handover."
"That's right," I answered. "Systems outlast the people who build them. But the knowledge to understand them leaves with those people. To build a system that someone will still be operating thirty years from now, you have to design the transfer of knowledge with the same care you give to the technical architecture."
Outside, the sky was deepening to a rich blue in the evening light.
Nine months later, a report arrived from John.
The CSV conversion tool was implemented in time for the autumn business launch. Data submission to the trading partner began without issue. The full replacement — progressed in parallel — had data migration completed before the two employees' retirement. The handover documentation ran to 170 pages.
The new system launched with zero customizations. Three months into operation, no one had reported being unable to work without asking for help.
John wrote: "Breaking the problem into six coordinates with the 6D-MATRIX changed the conversation with the two staff members. It became not a space for asking 'why did this happen' — but a space for designing 'what do we do from here.' Getting thirty years of history out of them required questions pointing in that direction."
The code left behind by a designer thirty years gone became a gift to the next thirty years.
"Problems in a thirty-year-old system don't begin with technology aging — they begin with the disappearance of knowledge. The 6D-MATRIX provides six coordinates where a time axis (present, past, future) intersects a perspective axis (WHY, HOW, WHAT). Filling all six boxes reveals the structure behind the symptoms — and separates what to resolve immediately from what to change over time. Decomposing a problem is the act of making the solution simple."
Related Files
Tools Used
- ROI Polygraph — Quantifies knowledge concentration risk and operational stoppage scenarios
