The rewrite trap

Somewhere in the first eighteen months, the person running technology at a small investment firm proposes a full rewrite.

It is a stable pattern. The stack was assembled quickly, often by someone who was not an engineer, usually in whatever tool was nearest. It works. It is also slow, undocumented, and terrifying to change. The new technology owner looks at it, forms a view, and takes a proposal to the partners: give me four months and I will replace the whole thing properly.

I have made a version of that argument more than once. I no longer think I was right, and the reasoning that convinced me at the time was good enough that it is worth setting out carefully, because the same reasoning is being deployed in a partners’ meeting somewhere this week.

Why this happens to investment firms specifically

Software teams everywhere are tempted by rewrites. Small investment firms have a particular set of conditions that turn a temptation into a near certainty.

You are usually the only senior technologist. The largest technical decision the firm will make in five years gets no peer review, because there is no peer. There is no architecture forum, no staff engineer who has watched a rewrite fail before, nobody whose job it is to ask what happens in month seven.

Your users cannot evaluate the proposal. The eight to thirty people you serve are portfolio managers, analysts, risk, operations and the founding partners. Every one of them is commercially senior to you and none of them can assess the technical merits. So they approve it. It is important to understand what that approval is and is not. It is trust in you. It is not validation of the plan. Those feel identical in the room and they are completely different things.

Nothing external constrains scope. There is no customer, no release train, no competitor shipping next quarter. In a product company, a rewrite collides with a roadmap that somebody else owns. Here the only forcing function is you, and you are the person who wants to do it.

The stack was built for a firm that no longer exists. It was built when the firm ran two strategies and had twelve people. It now runs five and has thirty. That change is real, it is visible daily, and it makes the “this does not scale” story feel obviously true rather than like something requiring evidence.

Failures are expensive and immediate. A reconciliation break, a stale price, a risk report that does not run before the morning meeting: these have direct financial consequence and everyone in the building knows it. High stakes raise the emotional temperature, and a high emotional temperature makes drastic action feel proportionate. It usually is not.

At systematic firms there is one further condition. A real latency or throughput argument is available, and it legitimises technology choices that would not survive scrutiny anywhere else. If your firm’s edge is partly execution speed, “I need a faster language” is not obviously a rationalisation. Sometimes it is not one. Sometimes it is.

The four arguments, and what is wrong with each

“The performance problem is architectural”

Occasionally true. Usually it is three queries, a missing index and a synchronous call that should be a job.

The test is trivially available and almost never run before the proposal is written. Profile it. Find the actual hot path. Name the slowest thing and how long it takes. If you cannot produce that number, you do not have a performance problem, you have a feeling about a performance problem.

I would go further: the fact that the number has not been measured is itself diagnostic. Measuring is unglamorous and takes two days. Rewriting is interesting and takes four months. The absence of the measurement usually tells you which of those you actually wanted to do.

“The current stack cannot scale”

Scale to what.

This is the question to ask out loud, with a number attached. The firm has twenty-eight people, four strategies and a universe of nine hundred instruments. What is the projected figure in three years, and what specifically breaks at that figure?

Most of the time the honest answer is that nothing breaks. The system is not near a limit. It is near the limit of what you can comfortably change, which is a different problem with a different solution.

“Nobody else can maintain this”

Key person risk in a small firm’s stack is real and it is under-appreciated by everyone except the key person. But look at what the rewrite does to it.

For the duration of the project, exactly one person understands both systems, the migration path and the sequencing. That person is you. Key person risk does not decrease during a rewrite, it roughly doubles, and it stays doubled for as long as the project runs.

Then look at the destination. The replacement is typically written in a language or framework you chose, and you chose it partly because you like it. If the original problem was that the firm depended on one person’s mental model, rebuilding it in a stack that fewer people in the local market know is not a fix. It is the same problem with better tooling.

“We will get it right this time”

This is the one that does the damage, because it is the only one that is about you rather than about the system.

The existing code is ugly. Some of that ugliness is incompetence. Most of it is encoded requirements. It is the special handling for the instrument the firm traded twice in 2021, the timezone correction for the one data vendor whose files arrive an hour early on the last business day, the manual override the head of operations asked for during a bad week and everybody forgot about.

None of that is documented. All of it is load-bearing. You will rediscover it one production incident at a time, and each rediscovery arrives as a surprise in front of an audience.

What it actually costs

Assume the four months is a good-faith estimate. Here is what the estimate leaves out.

You now run two systems. The old one does not stop needing changes, because the firm does not stop trading. Every request from the investment team during the rewrite has three possible answers: build it twice, build it in the old system and port it later, or tell them no. All three are worse than the situation before you started.

Your estimate is anchored on what you can see. You scoped the visible functionality. The invisible functionality is the part that took four years to accumulate, and it is the majority of the work. This is why rewrites do not overrun by twenty per cent. They overrun by a multiple.

The requirements move underneath you. A four-month rewrite of a stable product is hard. A four-month rewrite of a system that supports an investment process which is itself changing is a different category of problem. The firm launches a strategy. A new data source arrives. The risk framework changes. Each of those lands on both systems.

The credibility cost is the one nobody prices. You asked the partners for four months. You return at month nine with something that mostly works. What you have spent is not nine months of engineering time, it is your ability to ask them for anything. And you will spend it at precisely the moment you need it for something that matters, because in a small firm the technology owner gets roughly one large ask per year and you have used yours.

Then the opportunity cost. Nine months of the firm’s only senior technologist, not spent on the reconciliation process that consumes two operations days a week, or the risk report that cannot be produced intraday, or the fact that the analysts still model in spreadsheets that nobody has version controlled.

What to do instead

None of this means the system is fine. Usually it is not. It means the full replacement is the most expensive available route to fixing it and rarely the fastest.

Get a number, and get it in front of someone else. Not “the system is slow” but “the overnight run takes four hours and twenty minutes, it has to finish before 07:00, and it has missed that twice this quarter”. A number can be argued with. A feeling cannot, which is why feelings survive meetings that they should not survive. If nobody outside the technology function has seen your number, you have not tested the argument, you have only tested whether people trust you.

Separate two questions that feel like one. Does this codebase cost the firm money, and do I dislike working in this codebase. Both can be true. Only the first justifies spending the firm’s capital. Answer them on different days.

Find the seam. In an investment firm’s stack there are usually three natural ones: data ingestion and normalisation, the calculation and analytics layer, and reporting and the user-facing layer. Put an interface in front of one, replace what sits behind it, and leave everything else alone. Each is independently shippable, independently reversible, and independently valuable if you stop after the first one.

Buy the boring parts. Market data plumbing, reconciliation, standard reporting: these are not where a small firm differentiates and they are the parts most likely to consume a rewrite’s schedule. Somebody sells this. Paying them is usually cheaper than nine months of your time, and the comparison is worth doing explicitly rather than by instinct.

Replace one module and see if anyone notices. This is the cheapest information you can buy. Take the single worst component, replace it, and observe. If the investment team’s experience is measurably better, you have evidence for the next one. If nobody notices, you have learned something important about the other twelve modules and it cost you three weeks rather than nine months.

Write the one-page memo. Not a technical design. One page explaining to the chief investment officer what changes for the investment team, when, and what it costs. If you cannot write that page, the project is not aimed at their problem. That is worth knowing before the build, not during it.

Three questions

If you are the technology owner at a small investment firm and you are drafting the rewrite proposal, these are worth sitting with before you send it.

The third one is the difficult question, and it is the reason I wrote this. The rewrite is uniquely seductive to a technology owner working without direction, because it is the one project in the building that comes with its own complete specification. You do not have to go and find out what the firm needs. The existing system tells you exactly what to build. That is what makes it feel like clarity, and it is also exactly what makes it a substitute for the harder work of establishing what the firm actually requires.

If the honest answer to the third question is that nobody asked, that is not a reason to abandon the idea. It is a reason to go and have the conversation you were avoiding by proposing it.