Prove the files you were handed do what they claim before you build anything on them.
This failure hasn’t changed in forty years. It’s only found new places to happen. A vendor sends a specification that doesn’t match what their interface returns. A migration runs against documentation nobody updated. An AI tool gets pointed at a branch that no longer reflects production and confidently rewrites code that’s not there anymore.
In every one of those, somebody asked, somebody answered in good faith, and the answer was wrong.
Why do software ports take longer than expected?
Usually because the inputs weren’t what everyone believed they were.
A port looks like the safest work in software. The program already exists. It already works. Somebody wrote it, somebody tested it, and customers use it. All you have to do is move it.
Estimating that job is easy, which is exactly the trap. Nothing in the estimate accounts for the possibility that the thing you were given isn’t the thing that runs.
What happens when the source code does not match production?
A company that made the nails for roofing trusses gave their customers a free program. You fed it some inputs and it designed a roof truss for you. The nails are flat pieces of metal with sharp points that hold the wood together, and that was the whole business.
The program ran on an older machine and they wanted it on the personal computer that was becoming standard at the time. A straight port. No new features and no redesign.
I wasn’t the project lead. I was the interface to the client. That means the files came through me.
We asked them for the sources. They sent them. Nobody skipped a step and nobody was careless.
Then the port wouldn’t work. The team tried, and tried differently, and burned weeks on a job that should have been simple. Eventually we got the right sources, and it worked immediately.
The sources we started with weren’t the ones in production. The person who pulled the files believed they were current. They weren’t, and nobody in the building knew.
How do you verify a vendor gave you the right files?
Run them and confirm they produce what’s already in production.
Before any work begins, build the thing you were handed, run it, and check the output against the version customers are using. If they differ, you’ve found the problem on day one instead of week three.
It costs an hour. Skipping it cost us weeks and there was no way to detect the difference from the outside, because the wrong sources looked exactly like the right ones. Same file names. Same structure. Same everything except behavior.
The same test applies to almost any handoff. Run the vendor’s example against their interface and compare it with the documentation. Take one record through the process the runbook describes and see whether the runbook is accurate.
What happens when AI is pointed at the wrong version of your code?
The same thing, faster and with more confidence.
An AI tool reading a stale branch produces work that’s internally consistent and externally wrong. It refactors functions that were removed months ago. It updates calls to an interface that changed. It writes tests for behavior nobody ships anymore.
None of it looks wrong. That’s the difficulty. Bad output from a confused tool arrives formatted, commented, and plausible, which is the same problem the roofing truss sources gave us, except it now arrives in seconds rather than in a box.
The defense is unchanged. Establish that the input reflects reality before anything gets built on it.
Who is responsible when the inputs are wrong?
Nobody, and that’s why it keeps happening.
The client believed they sent the right files. The person who pulled them believed the folder was current. We believed what we were given. Every individual acted reasonably and the project still lost weeks.
Blame has nowhere to land here. What’s useful is noticing that the failure lives in the handoff itself rather than in either party.
I sat in that handoff. I was the person talking to the client, and I asked correctly, and I received what I asked for. Doing my job properly wasn’t enough to keep the wrong thing out.
Anyone in a small company who sits between a vendor and their own team occupies the same position. The engineers cannot verify what they were handed, because they’re not the ones talking to the people who have it.
How do you check a handoff before you start work?
Three questions, asked of whoever hands you anything.
When was this last used in production, and by whom. Where did you get it, and is that the same place the running version comes from. Is there another copy anywhere, and do the two match.
None of those questions is an accusation. They’re the same questions you’d ask about a used car, and nobody finds them rude in that context.
Then run the thing and compare it against reality. The questions establish provenance. Running it establishes truth, and only one of those is actual evidence.
Why do project estimates go wrong?
The project made the firm a lot of money. It wasn’t a disaster. It was a job that took considerably longer than it should have.
The lesson I took was narrow and I’ve used it ever since. Make sure you have the right sources, or access to the right sources, before you start. This was decades before anyone could check a version history from their desk, and the principle survived the arrival of the tools that were supposed to make it unnecessary.
Asking isn’t verifying. The client sent what they had. What they’d was wrong, and no amount of skill on our side could close that gap.