Prove the files you were handed do what they claim before you build anything on them.
This failure has not changed in forty years. It has only found new places to happen. A vendor sends a specification that does not 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 is 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 were not 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 is not 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 was not the project lead. I was the interface to the client, which 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 would not 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 were not the ones in production. The person who pulled the files believed they were current. They were not, and nobody in the building knew.
How do you verify a vendor gave you the right files?
Run them and confirm they produce what is 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 have 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 is 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 is 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 is 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 is 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 was not 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 are 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 are the same questions you would 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.
What did the truss project teach about project estimates?
The project made the firm a lot of money. It was not a disaster. It was a job that took considerably longer than it should have.
The lesson I took was narrow and I have 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 is not verifying. The client sent what they had. What they had was wrong, and no amount of skill on our side could close that gap.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.