← All insights
Engineering
When to Rewrite a Roblox System and When to Leave It Alone
Rewrites are tempting because the old code is unpleasant. That is not enough of a reason.
Old code is hard to read, and a clean start looks lighter than understanding it. But a working system holds years of fixes for cases nobody remembers. A rewrite drops that knowledge unless it is deliberately carried over. Sometimes the rewrite is right. The decision should rest on evidence about cost, not on how the code feels.
The temptation
- The code is unfamiliar or ugly.
- The original authors left.
- Every change feels risky.
- A new design would be cleaner.
None of these is a measurable problem. They are reasons to understand the system, and possibly to clean it up.
Start with what is measurably wrong
| Problem | How to measure it |
|---|---|
| Too slow | Profile at target load and find the actual cost |
| Too many bugs | Count and categorise recent bugs by system |
| Slow to change | Time how long typical changes take and why |
| Hard to extend | List the features you cannot add and what blocks them |
| Data issues | Track corruption, loss or inconsistency incidents |
If you cannot measure the problem, you cannot tell whether a rewrite fixed it.
The costs of a rewrite
- Opportunity cost
- Time not spent on features or fixes players need.
- Hidden behaviour
- Edge cases the old code handled and the new does not.
- Compatibility
- Existing player data, saved states and content built on the old system.
- Migration
- Moving live data and running two systems during transition.
- Risk
- A big change in a live game with real players and real spending.
Incremental alternatives
- Add tests around the current behaviour first. They protect any future change.
- Isolate the problem part and replace only that part behind the same interface.
- Wrap awkward code in a clearer interface and leave the inside alone.
- Remove dead code and duplicates.
- Apply new design to new features while old ones continue.
- Replace gradually, route by route, and keep the old path until the new one is proven.
When a rewrite is justified
- The current design cannot support something the game must do, and workarounds cost more than replacement.
- The problem is measurable and tied to the structure, not to a few functions.
- Data and behaviour can be migrated safely, with a way back.
- The team understands the old system well enough to preserve what matters.
- The expected benefit exceeds the cost, with a margin for overruns.
Decide in writing
- Describe the problem and the evidence.
- List the incremental options and why they do not meet the need.
- Estimate cost, risk and time honestly, then add contingency.
- Define success and how you will check it.
- Plan migration and rollback before starting.
Debt left alone has a cost too. See Why Technical Debt Becomes a LiveOps Problem. The aim is to choose, not to avoid rewrites.