
Ask HN: How to prioritise codebase health/design over new features in a startup? - achie27
I work in a startup that is in the scaling-up zone and every now and then there&#x27;s some adhoc feature request or unforeseen circumstance that forces me to tweak my codebase in a way I don&#x27;t want to - like putting a &#x27;temporary&#x27; hotfix and just injecting a new logic without creating a separate&#x2F;proper pipeline for it. There is no systematic testing flow or code coverage either. Its almost too sad that this service hasn&#x27;t had its share of cleanup given its importance.<p>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.<p>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?
======
protonimitate
> 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.

------
gtirloni
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.

------
GrumpyNl
Small steps.

