Will It Build?
43 minThis might sound crazy, but all I want is to get this thing to build. We take our time inside the SubSonic codebase and come out the other side with a concept of a plan, which is not quite the same as a plan.
It works, mostly. It makes money, definitely. And every year the gap between what it runs on and what you would hire for gets a little wider. Nobody gets promoted for touching it, and everyone is quietly dreading the day they have to.
Mine is called SubSonic. I wrote it, it shipped inside real products, and it has been sitting on .NET 3.5 since roughly the year the iPhone came out. So rather than upgrade it quietly, I asked Jon Skeet to do it with me in front of a camera.
“Owning every questionable decision in the codebase, and explaining them under oath.”
SubSonic is the patient. The procedure is the point, and it transfers to whatever twenty-year-old codebase is haunting your shop.
They want a tidy solution file, passing tests, and a team with spare time. Your legacy code has none of those things, which is exactly why the guides do not help and why the upgrade keeps sliding to next quarter.
What helps is watching two people actually do it, out loud, with the dead ends left in. We do not know what will work either. That is the honest part, and it is the part you can copy.
Every year you postpone, the jump gets bigger and the people who remember how it works get further away.
So I wrote SubSonic. It got popular, it shipped inside real products, and then, like all of us, it got older. It is still out there, still full of decisions that made perfect sense at the time and look deranged today.
The sessions are edited hard, so you get the decisions, the arguments, and the dead ends worth seeing, with none of the waiting for builds.
Every session maps to a step you can run on your own codebase the next morning.
Reading a codebase you did not write, or wrote and forgot, so you can size the job honestly. No more "it is 90% done" for six straight months.
Characterization tests around untested code so you can change it without breaking behavior nobody remembers. You refactor with confidence instead of prayer.
Old csproj to SDK-style, .NET 3.5 to .NET 10, in an order that keeps the build green while the foundation changes underneath it.
Jon applying two decades of language evolution: nullable reference types, generics, modern APIs. What to adopt, and what to leave exactly where it is.
Where Claude genuinely helps with a big migration and where it will cheerfully wreck it. The speed without the slop, which is the difference between weeks and quarters.
Knowing when it is done: what to modernize, what to leave alone, how to release. The project ends instead of becoming the new legacy problem.
The top-ranked contributor in Stack Overflow history. If it is in the C# spec, Jon has an opinion about it, and he is usually right. He brings the language depth this upgrade deserves, and the refusal to accept any claim without a repro.
Wrote the code we are fixing. Founded Tekpub, wrote The Imposter's Handbook, and spent a decade at Microsoft including three years on the VS Code team. Owns every questionable decision in this codebase.
Because the hard parts of a migration are never the syntax. They are the order you do things in, the moment you decide a rewrite is cheaper than a fix, and the discipline to keep the build green while the ground moves.
You get Jon on the language, me on twenty years of my own bad decisions, and Claude Code in the middle doing the work that used to take a week of evenings. Nothing is rehearsed, which is the only reason it is useful.