You're going out of scope, again.

Hello,
I'm a front end developer, I work in a Saas company.
Various apps/projects, agile approach, Jira tickets, git, teams. That is the gist of it.

I have one problem. A technical one, maybe behavioural, maybe moral:
when I get assigned a new story I struggle to stay in scope.

I'll go with an example:

An app with not more than 3 dozens React components, a fairly complex Redux store and a few API calls. It's not a massive app.

My story is to add, conditionally, a new level of nesting in a list: now some items have subitems, need to change the UI, probably mess a bit with the state/store.

The code app in my opinion is hard to read, eg. every react component is HOC'ed with a redux wrapper. Or state has too much derived data in it.
Or the file structure is wrong, components have long names, they are organised by type, not by feature and there's a lot of them now.
Or there is no strategy in regards of code formatting, I want no semi, my colleague does. Etc.

I'm not blaming someone else, I was part of the team that made the app like that, months and months and months ago, at the beginning of our React journey.

During this time I obviously improved so that code, that I feel responsible for, I just cannot accept it. Actually it became so complex that I'm struggling to reason with it!

Assume I'm the only one working on the front end of this app at this moment.

I'm about to go over time because I started to send PR with refactors: prettier on pre-commit to keep it consistent on git, organize the files in the area around my story by feature, remove nested redux HOCs and just pass props 1, max 2 level down and other small refactors. I'm also coding the actual story I was originally assigned but this is obviously taking more time.

I could have proposed the changes, worked at my story and maybe later, in the future, implement those changes following the process.

Making this 'big' changes, not strictly related to the assigned story is not right.
It may ruin other people plans. It's just not really good. But I kinda forced my stakeholders into taking those changes.

Although now the code is already in a much better state and I can finally work with it effectively.

What should I've done?

Comments

[rhymes]

It looks like you're fighting against technical debt and the time you're supposed to take to implement a new feature.

You should probably do all of these depending on the situation:

• ignore the debt for some specific features
• communicate with the rest of the team what the issues of the code are and allocate specific time to lessen the technical debt
• declare more time for an actual feature (if you think the feature is supposed to take 2 hours, tell your PM it's going to take 4 so that you can clean up a bit)

If you spend 3 days "isolated" for a feature that was supposed to take 2 hours because you started rewriting the entire app then you definitely have a problem :D

[Albino Tonnina]

Ciao rhymes, thanks!

What you say is fair but let me give you some relative data so you can evaluate better.

The story would have taken a few days, let's say 3. These refactors costed another 1 day, plus one day and a half that I spent trying to actually remember what that code does, because of the way it is written.

Now in 2 days I can, with a code that smell way less, do the feature.

Having said that, in my limited experience, the NFRs I would ask to get my refactors done, would hardly be put in the calendar anytime soon, understandably, don't get me wrong.
That's the point of my post: I forced my company's hand to make something (I hope) good for it.

[rhymes]

Ok, so it's definitely a communication problem. Have you tried to talk to them, outside of the moment you're developing a feature, about the technical debt?

[Albino Tonnina]

Of course, and actually nobody is against it.

I'm really not blaming anyone. It's maybe an issue of pace, or momentum if you will.

Even myself, let's say in a month or so, with some time to make those nice refactors, I may probably be interested in a new project I've been assigned to. Totally absorbed by other issues there.

The motivation could get lost or I don't know, the feeling that I may be working in some other place and that would became my legacy, some smelly code.

[Kat]

Some smelly code isn't the worst legacy to leave behind. Generally people won't fix it so it becomes technical debt which is why people probably left you alone on it.

You're right though, I think. You're fighting your past self, but mostly I just go "what the hell was I thinking" and if I have time, work in refactor time through actual banked off refactor time in support of a feature or something so it works better (improvement) or actual just devoted refactor as a means of maintenance so it has proper testing, if possible, but it depends on your fires, your resources and whatever else is going on.

[Grumpy and]

Great question. Every situation is different, but your question cuts to the heart of things: how to keep technical debt low while staying on deadline.

I'm on deadline myself, so this will be more a collection of thoughts than actual advice. I hope it's good food for thought.

• You don't mention tests. (By that, I mean: automated unit/integration/regression tests.) If you have them, great. If not, the team should strongly consider adding them as you build new features. They'll make refactoring efforts like this much faster & less risky.
• I really believe that refactoring is best done in support of new features. In other words, I avoid refactoring just to clean up the code. Instead, I do it when a new feature makes it clear what refactoring needs to be done, and provides a context in which that refactoring can be QAed, etc.
• I totally support wanting to have pride in your work. And forcing your team's hand like this may be forgiven (especially if everyone likes your changes). But it really is best avoided. Communicate with your team lead/manager to make sure everyone's on the same page, and give them a chance to give you feed back on your plan.

It sounds like you're already thinking through a lot of this, which is awesome. Again, communication with your team, and with your team lead/manager is key here. It may not feel like it in the day-to-day, but you and your team will get far more accomplished (including needed refactoring!) if you're all supporting the same goals, and working from the same plan.

Cheers!

[Kat]

I apologized for something once because it wasn't perfect, but it got into a tight deadline. No one pressured me about apologizing or even made a comment but it was my pride and my ego talking. I think it was guilt.

[Guillaume Martigny]

Hi Poof,

Technical debt is struggle for everyone. I have (sadly) some experience on working with old code-base.
What I feel works best (professionally speaking) is to address the issue steps by steps. The smaller the steps, the better. Pareto principle style !

Maybe start with code formatting as it has little chance to take time or break something.
Then code your feature. If you have some time left, start to think of refactoring.

I sometimes feel like you, but often, I make change that won't be merged because :

• It break some weird use-case
• Take too long to be reviewed
• Just too risky

Of course, you should try to improve. We all have down time, use them to clean your old piece of code.