Software Firms Say They Cannot Hire for Their Old Technology. What Holds Them Back Is How Few People Can Read the Code.
We reviewed what developers use and want, one product firm's own words on hiring, and a survey on skills at large enterprises. Here is what we found, why every question waits for the same two or three people, the four ways forward, and the benchmark we would set.
Two engineers at the firm can read the product’s oldest code. Both have been there since the early versions.
On Monday one of them has four things waiting. A fault a customer reported. A question from product about how a discount is applied. A new engineer who started in the spring and still needs an hour a day. And a second new engineer, who starts today.
By Friday the fault is fixed and the question is answered. The two new engineers have had perhaps three hours each. The feature the two of them were meant to build this month has not been started.
The paradox: The more people the firm hires to ease the load on the few who can read the product, the more of those few people’s time the hiring uses up.
What We Found
For this article we went through the public record on products written in technologies that fewer developers now work in: one product firm’s own words in a case study published by a vendor, one large survey of developers in 2022 and 2025, one news report of a vendor’s survey on skills at large enterprises, and one engineer’s post on a developers’ forum about documentation drafted with AI tools.
Four findings stand out.
A product firm has said it in public. One maker of insurance software, describing its own product in VB6, an old business language, gave as a reason for moving that “recruiting new staff with the Visual Basic 6.0 skill set is becoming more difficult”. It is an older case, from about 2009 by the versions it names, and the account was published by a firm that sells a conversion tool. We use only the problem it describes, and we do not name the firm.
Few developers use the old technologies, and fewer want to. In one large survey of developers in 2025, Visual Basic (.NET), the later form of that old business language, was used by 4.4% of developers and wanted by 1.9% for the year ahead. VB6 itself was not listed. AngularJS, an old framework for web screens, was used by 7.2% and wanted by 4.0%. PHP, a web language, was used by 18.9%, down from 20.87% in 2022, and wanted by 9.2%. Delphi, an old desktop language, went from 3.25% in 2022 to 2.5% in 2025. These figures are about developers in general, not about software firms. “Not listed” does not mean unused, and “wanted by few” does not mean nobody will take the work.
The difficulty is the same shape elsewhere. In a vendor’s survey of “500 senior leaders at mainframe-based enterprises”, reported in the news, “Seventy percent of respondents have had difficulties finding the right skills”. Mainframes are large enterprise computers and not our kind of work. We use the figure only for the shape of the difficulty: old skills are hard to find.
A record drafted by a tool still has to be checked. One engineer, writing on a developers’ forum about documentation that teammates had produced with AI tools, put it plainly: “The AI docs are simply wrong, 100% hallucinations.” And: “Sometimes no doc is better than a bad doc.” It is one person’s account. We use it for one point only: whatever drafts a record of old code, engineers have to review it against the code.
Our reading is that a firm with an old product is rarely short of good engineers. It is short of people who can read one part of its own code, and every question about that part, from product, from support and from each new hire, goes to them. What turns the shortage into a limit on the business is that the code is the only record of what the product does.
What our review does not show: The research found one sentence from one product firm, in an older case taken from a vendor’s case study, and no named software firm whose business was harmed by a shortage of developers. No figure was found for how long a vacancy for an old technology stays open, what such developers are paid, how many there are, or how long a new engineer takes to become useful, in India or anywhere else, and we give none. The survey figures describe developers in general. The skills survey is about large enterprises that run mainframes. The forum post is one engineer’s account. That the missing written record is what limits the business is our reasoning, not a measured finding. The week in the opening scene is imagined.
What Waits While Only Two People Can Read the Code
A shortage of developers for an old technology is usually treated as a hiring problem. Our reading is that it is first a capacity problem, and hiring alone does not reach it.
The first cost is the roadmap. It is capped by how many people can read the code. However many engineers the firm has on current technology, the items that touch the old part of the product queue behind the same two or three.
The second cost is every question. How a feature behaves, why a customer saw what they saw, what a change would touch: each waits for one of the few, between faults.
The third cost is each new hire. What one newcomer was taught is not written down, so the next is taught again, by the same people, from the beginning.
The gap we see: most firms in this position do not need more people who can read the old code as much as they need fewer questions that only those people can answer. A written record of what the product does, checked against the code and confirmed by the firm’s own experts, lets engineers, product managers and newcomers find out what the product does without reading the old language. It also gives a basis for moving the product, a module at a time, to a technology developers will work on.
This is our reading of the evidence. It is not a measured market figure.
Four Ways Forward, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Leave the questions with the people who can read the code | The old part is small and rarely changes | The roadmap stays capped by two or three diaries, and nothing is kept when one of them leaves |
| Seat each new engineer beside one of them | Hires are rare and the experts have time to spare | The experts’ time goes on teaching, and what is learned stays in one more head |
| Have AI tools write documentation of the code | A quick first draft is wanted, and engineers will check it against the code | A record that reads well and is wrong, trusted because nobody checked it |
| Write down what the product does, checked and confirmed, then rebuild it module by module on a stack developers will work on | The product is large, sells every day, and few can read its oldest part | It costs money before anything moves, and old and new run side by side for a time |
Our recommendation: write down what the product does first, in plain language, from its own code: tools draft, engineers check each rule against the code, and your own experts confirm it. Then rebuild the product one module at a time, as a web application on a stack developers will work on, while the old product keeps selling. We are not a staffing firm: we do not supply, recruit or train developers, and nothing here fills a vacancy.
Where You Are Now, and Where You Should Be
A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own product, each with a target.
For this issue, the benchmark would look like this.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Functions of the product written down | Few or none; the code is the record | Every function in plain words, confirmed by your own people | The specification |
| People able to explain each module | Two or three, for the oldest modules | More than a few for every module, working from the record | The map of the product, reviewed at each stage |
| Modules on a current stack | None, or only the newest parts | Rising at every stage, with a date for each | Reported at every review |
| How a newcomer’s first change is checked | A senior engineer reads it from memory | Against the record, and by tests where they exist | The record of each change |
| Questions that wait for the same few people | Not counted | Counted, and falling | Your own engineering and support records |
The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a software firm.
How We Work With You
- We listen: a free Reliability Review. A first conversation about your product, who can work on which part of it and the questions that wait for them. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is your own product’s code, and the specification is written so that engineers who never learned the old technology can read it. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the product keeps selling while each module is rebuilt as a web application on React, Node.js, Python or Java, which engineers on a current stack can work on. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
- We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.
The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.
This approach has limits. We are not a staffing firm. We do not supply developers for the old technology or the new, we do not recruit or train your staff, we give no advice on pay or employment, and nothing we do fills a vacancy or keeps anyone. We have no assistant that answers questions about your code. We do not convert code by machine; we rebuild, as a web application on React, Node.js, Python or Java, and we do not build desktop programs or mobile apps. We do not maintain the product or the written record afterwards; your own team keeps both current. Until the last module has moved, you still need people who can read the old technology. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a software firm.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | What the firm knows about its own product stops being held by the few people who can read the old code, and belongs to the firm. |
| CTO or CIO | Engineers who never learned the old technology can find out what the product does from a record, and go to the code only when they need to. |
| Head of product | Product managers can read how a feature really behaves, and stop waiting for the one engineer who can look it up. |
| CFO | The cost of bringing a new engineer up to speed is no longer paid again, in the experts’ time, with every hire. |
| Head of people | Induction starts from a document, and no longer depends on how much time one colleague can spare. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| This article names no organisation. Its figures come from one product firm’s words in a vendor’s case study, one large survey of developers, a news report of a vendor’s survey and one engineer’s forum post. | Our assessment writes down what your product does, checked against the code and confirmed by your own experts. We then rebuild it one module at a time on a current stack while it keeps selling. We do not supply, recruit or train staff. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by reading your product once and writing down what it does, so that fewer questions wait for the few who can read the code.
Sources
In this issue
Few developers for the old technology