As our codebase has been developed over close to 10 years under one developer, it's acquired a lot of cruft, and also uses technologies that are fairly dated now. We're planning to do a rewrite of the codebase with our OEM partners, and I'm deciding what to do about the legacy code.
Do we:
- Take what architecture decisions worked and use the corresponding documentation to develop a new design?
- Transition the code base slowly from legacy to new (and hence inform the new hires how the legacy code works)?
- Start completely from scratch and retire the legacy code before bringing the new hires on?
We're going to have about 18 months at a minimum from the first hires to having a product in hand to bring to market.
I want to avoid using people's limited resources on technologies that I know we're going to retire, and just want to see how best to go about that.
How have you handled this transition in your experiences?
It may seem like a small detail, but declaring your only codebase “legacy” before you have a replacement is a bad move if you have any customers or active use cases at all. You may not like the old project, but you need to be honest with everyone that it is your bread and butter until the new codebase is written. If you start calling it “legacy” and pretend that new hires will only ever be dealing with something that doesn’t exist yet, you’re setting everyone up for disappointment when business realities make the old codebase active for far longer than you expect.
I’d hire now, and hire with the expectation that new hires will be working with both old and new codebases. Don’t set your company up for a situation of competing codebases, or worse, competing developers depending on which codebase they’re each working on.