

Ask HN: How to inform management about much needed refactors - TheM00se

My situation is that I&#x27;ve recently been hired by a startup that hasen&#x27;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.
======
auganov
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 :)

~~~
TheM00se
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.

~~~
kohanz
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.

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

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

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

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

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

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

