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.
This one still stands out as a waste. Nobody did anything wrong and we lost weeks anyway, and that’s the kind of failure I find hardest to live with, because there’s nobody to be angry at. I think the handoff is the most dangerous moment in any technical project, and most teams treat it as paperwork.
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, and that ease is the trap. Nothing in the estimate accounts for the possibility that the thing you were given isn’t the thing that runs. I don’t trust any estimate on a port until somebody has built and run what they were handed.
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. Watching that was miserable. Good engineers spent weeks chasing a problem that had never been in their work, and nothing on the screen could tell them so.
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. That’s the same problem the roofing truss sources gave us, except it now arrives in seconds and not in a box.
An AI tool reading a stale branch produces work that’s internally consistent and externally wrong.
The defense is unchanged. Establish that the input reflects reality before you build anything on it. I use AI tools every day, and the one thing I’d never do is hand one a folder nobody has checked against what’s running, because a confident machine working from the wrong files does damage faster than any person could.
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. The failure lives in the handoff itself, and the cost lands on whoever pays for the lost weeks, which in a small company is usually the owner who signed off on an estimate that assumed the files were right.
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 can’t 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.
| Check | What to ask or do | What it establishes |
|---|---|---|
| Last production use | When was this last used in production, and by whom? | Provenance |
| Source | Where did you get it, and is that where the running version comes from? | Provenance |
| Other copies | Is there another copy anywhere, and do the two match? | Provenance |
| Build and run | Run what you were handed and compare it with what customers use | Truth: problems surface on day one, not week three |
| Vendor interface | Run the vendor’s example and compare it with the documentation | Whether the spec matches what the interface returns |
| Runbook | Take one record through the process the runbook describes | Whether the runbook is accurate |
| AI tools | Never hand one a folder nobody checked against what’s running | A confident machine on the wrong files does damage fast |
My take
Unverified handoffs cost more project time than any other mistake I’ve watched. We asked a client for source code, got the wrong version, and a simple port turned into weeks. Spend the hour before work starts. Take one record through the process and confirm the files match what’s running. That goes double for AI tools, because a confident machine on the wrong branch does damage faster than any person could. Check the input first, every time.
Why do project estimates go wrong?
The project made the firm a lot of money. 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 had was wrong, and no amount of skill on our side could close that gap. I’m stubborn about this now. I think any team that skips that hour to look fast is gambling with somebody else’s money, and the bill always shows up in weeks.
Build a Profitable Consulting Practice starts with my first job, where I did everything wrong, beginning with never validating my assumptions. The book covers the part of consulting nobody teaches.
