The path from one developer struggling with an inherited Android codebase in Delhi to a lab that builds custom tools, methods, and tradecraft for the code most engineers will only ever read, never write.
I picked up Working Effectively with Legacy Code because I had no idea how to maintain the codebase I had just inherited. There were no tests. There was no architecture. I was supposed to hire a team around it.
I was at a financial-technology company in Delhi, taking ownership of a codebase another agency had built. No tests. No architecture. I was supposed to hire a team around it. I bought Working Effectively with Legacy Code in February. It was the first time I saw the problem named.
Two years later, consulting on a much larger client, I ran into the same problem at a different scale. I tried UML diagrams. The complexity ate them. I started experimenting with custom visualisations — Observable notebooks, hierarchical edge bundling, force-directed graphs — to filter and transform a codebase until I could see it. That was the first taste: the right view of the right slice of code is often the whole job.
Three books became the through-line of everything that followed. Feathers gave language to the problem; Tornhill gave a method for seeing it. After that the work was building tools that do the seeing.
Across very different clients with very different stacks, the same shape kept showing up: high-churn, high-complexity files clustered at the top or the bottom of the conversion funnel — old code, many authors, often very large. I was asked, again and again, to break them down. So I started building a tool for exactly that job.
By 2023 the question I’d been chasing for six years had a name and a shape. I bought the domain because this is the area I want to work in — not “modernisation,” not “platform,” not “DevX.” Legacy code. The code you didn’t write. The most code there is.
On January 1, 2024 I incorporated Legacy Code Labs and started work on Appsplitter — a tool aimed squarely at the pattern from 2022: modularising large monolithic Android codebases. I worked on it for the better part of two years.
By the end of 2025 it was obvious AI had become capable enough to re-shape the work. I committed to a polyglot stance: not just Android, not just one stack — any codebase, any language. I doubled down on deterministic tooling for both comprehension and refactoring, and started building a new family of in-house tools.
Generate readable, navigable mental maps of unfamiliar codebases — for humans first, agents second.
Topographic views of repositories: where the load-bearing code lives, where the rot is, where to start.
AI is now writing a lot of code — and a lot of it is hard to understand. The work of the last nine years compounds against exactly this problem. So this is the year I stop being quiet about it. The methodology, the tooling, the way of approaching engineering — all of it goes outward.
If most of the code you’ll touch this year you didn’t write, that’s the discipline. Not a side quest.
Whether you have a 4,000-line file no one wants to touch, or an Android app whose build is six minutes and climbing, or a polyglot codebase you inherited last week — the lab is open.