Ask HN: How to inform management about much needed refactors | Hacker News Reader

Ask HN: How to inform management about much needed refactors

6 pointsTheM00se9 comments

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.

View on HN

So what's the business case? The fact that you hate the current code is not. As a manager (and a developer) I'd be very wary of letting a new employee refactor a project that they are unable to work with. If they cannot work with it do they understand what it does? Do they understand future plans of the company? Will their refactor be objectively an improvement? Will they even finish the refactor? Doing a major refactor is a major risk. I was involved in a couple of refactors that only resulted in a different mess. If you want to convince me to do a refactor I need a strong case that will answer all the doubts.

Sorry if I came across as harsh :)

The original engineer who came up with the code has laid out several key areas that need serious reworking within the documentation. The code base is a few years old and 30% of it is deprecated. In order to implement the new features, the code base will have to be refactored to better accommodate those features since the current code base has no such ability to accommodate such features.

You're getting closer to a business case, but if you're confident in your assessment, you need to put it plainly, in terms that management can digest quickly. The bottom-line is money, and in engineering, time = money.

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.

Give a little and get a little. Tell them that the code really has served well until now but it has grown to a point now that it is like an avalanche of issues and you are convinced it won't support too many more features and changes. Then give them a few updates of the easier features in turn for letting you redo a section of code, and keep moving it forward that way.

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.

Do you mean refactor or rewrite? If you actually mean rewrite, then get a better plan. Figure out how to proceed with a phased refactor based approach. Fold the refactoring into new features.

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.

Refactor, there are 3 modules that cause 75% of the crashes.

This will always be a constant battle. Management wants new features asap and developers want to make the code base better. I've been there many times.

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.

I'm not sure it's even possible to sell a good percentage of managers on the needs of a refactor no matter how good your arguments are. Many of them either don't have the technical chops to even understand the need for major refactorings (no matter how much you "educate" them), or consider the technical debt accumulation an acceptable risk vs a perceived low ROI with refactoring.

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.

Good advice, but when you give "correct" estimates (not pessimistic but realistic) you may be perceived as beeing a slow programmer.

Reply on news.ycombinator.com