Ask HN: How to prioritise codebase health/design over new features in a startup?

#1

Post by achie27 » Mon, Oct 28, 2019, 1:38 PM UTC

I work in a startup that is in the scaling-up zone and every now and then there's some adhoc feature request or unforeseen circumstance that forces me to tweak my codebase in a way I don't want to - like putting a 'temporary' hotfix and just injecting a new logic without creating a separate/proper pipeline for it. There is no systematic testing flow or code coverage either. Its almost too sad that this service hasn't had its share of cleanup given its importance.

Now, I am at the bottom of the barrel here and not the original creator of the repo. It is a clusterfuck tbh and I really want to refactor it. The thing is, this repo connects to almost everything else in the ecosystem and taking the time out to refactor it is not going to bode well for a number of interdependent features.

How did you guys proceed when your microservice was getting out of hand with all the new features? And what do you guys prioritise, as a SWE, the health of your service or new (and apparently important) features floated by the product team?

Re: Ask HN: How to prioritise codebase health/design over new features in a startup?

#2

Post by GrumpyNl » Mon, Oct 28, 2019, 1:48 PM UTC

Small steps.

Re: Ask HN: How to prioritise codebase health/design over new features in a startup?

#3

Post by gtirloni » Tue, Oct 29, 2019, 12:54 AM UTC

Show how much time you're spending on working around broken things. Convert that to dollars and missed opportunities, slower execution, etc. And you should have a compelling case for focusing on refactoring. Without management buy-in, this will be impossible...

But yeah, as already said here, small steps. Do this for small areas of the code and stay away from the feared major rewrite.

Re: Ask HN: How to prioritise codebase health/design over new features in a startup?

#4

Post by protonimitate » Tue, Oct 29, 2019, 3:07 PM UTC

> And what do you guys prioritise, as a SWE, the health of your service or new (and apparently important) features floated by the product team?

It's cliche, but implement the "leave it better than you found it" rule.

I'm in a similar situation at my job, we're in the "push out as many features as possible" phase and POs don't know/don't care about the trade offs. I started baking in 20% more time into an estimate to allow me enough room to refactor/add missing tests/general clean up.

I would caution against going in and doing a massive refactor unless it's absolutely necessary. The reason being that refactors are usually much more involved than they appear on the surface, and can also have unexpected side effects.

I understand the urge to want to burn everything down and start with a clean slate... but it's generally more work than its worth. Try to identify the worst areas of the code base, like core business logic missing tests, and try to chip away at it.