Ask HN: When onboarding people to a startup, how do you talk about legacy code? | Hacker News Reader

Ask HN: When onboarding people to a startup, how do you talk about legacy code?

3 pointsidealmedtech3 comments

We recently received an SBIR Phase II grant, and while there's not money for new employees yet, it's got me thinking about how I'm going to onboard our first technical hires (currently just two founders, one technical, and a CEO).

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?

You’re in the danger zone where the current codebase has been mentally deprecated, but no replacement exists yet.

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.

Great perspective, thank you for that! We don't currently have customers, so it's kind of a unique scenario where we _could_ potentially sunset older stuff and start fresh with no impact, but I appreciate the advice. I think the hybrid approach may be best here.

What if you fashioned what you just said into an interview question? Perhaps phrase to be careful that you aren't asking for free consulting. Maybe candidate reaction could indicate who might be a good person to help with that problem.

Reply on news.ycombinator.com