Ask HN: How to inform management about much needed refactors My situation is that I've recently been hired by a startup that hasen't maintained its code base for 3 years. Im unable to actually add any new features to the mobile app until I refactor the code base into a much more manageable state, but this is super unpopular with the CEO and project manager who both think that there is no business case for a refactor since they need features. |
Sorry if I came across as harsh :)
So here's the case: the time to add the new features on top of current implementation + the time to support this new, perhaps brittle, version = X. The time to refactor the application and add the new features + support the new, perhaps more robust, version = Y. You must show, in reasonable detail and with confidence, that X > Y.
To this exact point. I recently have been involved with a company in a consulting gig. The reality is they need to just shit can their code base and start over. The fact is they can't do that, so we are adding features to their code base while we are also revising it in significant ways. We were just very up front and said that we cannot guarantee the changes at this point because the code is extremely fragile.
Also, part of what helped sell them at least, was my discussion that hey, what worked a couple of years ago was great, but today it isn't serving the needs of the clients so we have to rethink what is being done. Not saying they prior team was bad or incapable, regardless of my personal feelings. Maybe the same will help you.
Learn to speak in terms that the deciders understand. Speak in terms of FTE hours (cost) and reliability (risk). Speak in terms of What you're doing, not How. When you speak in terms of how, you're just inviting people to micromanage you. They really want to know how many FTE hours doing something is going to take, and how much risk they are exposed to. How you accomplish it is up to you.
If you tell them that next feature will take a year (because you're going to rewrite everything 1st), then they'll probably tell you to take a hike. So, you'll have to figure out how much refactoring you can do with each added feature to still make them happy.
Finally, you can't care more about the problem than the customer (in this case, your employer). You should care about your work, but don't put yourself in the position where you're more emotionally attached than the owner.
Just be honest. You will have to show them why it's a problem, you can't just tell them. Add new features onto the code base and show them how long it will actually take you.
My advice: Don't tell them unless you think you have to rewrite the whole thing or huge chunks of it. Refactor as you go, and adjust your estimates accordingly.