4

I feel like i am being forced to own a shitty module in our codebase.
It was developed by previous owners and they made a frankenstien monster out of it: Its one part of codebase that is very huge, does not follow the code standards, is making complex kinds of api calls and using very niche components. It gets bugs once in a while BUT IT WORKS.

It fuckin works and is one of the important steps before customer purchases a company product, so kinda part of revenue generation flow.

But this module was never a part of our codebase which we would usually touch. it was owned by another team, they would add enhancements , new features to it and fix the bugs .

When i joined the team, i was once asked to help those guys as a "resource" because they wanted to get something shipped and were low on bandwidth. So i just worked on one of the screens, added a small bugifx and voila, task is done and am back to other part of the app.

But now out of random, they decided to pass on the ownership to ur team, gave a small KT which didn't really explained a lot of actual codebase, but rather the business functionality of it(and that too poorly). And my TL is saying that i should own it because "I worked on that module before"

I don't know how to deal with this frankenstien monster. Earlier a bug came and i was out of my wits to understand why this bug came. their logging is weird and not explaining a lot, their backend devs help provide aws logs but those aren't very helpful either .

the best i could do was declare that their technical approach is wrong and we should modify it, but that idea was quickly squashed.

ITs quite possible that company isn't going to change this module or add any new features further. but everytime a bug would come, i would be getitngfrustrated looking at their frankenstien monster

Comments
  • 0
    where was that guy who said they'd introduce a module out of codebase to avoid peer reviews on merges? i think you would like to talk with them
  • 0
    @melezorus34 umm no such guy exist. the module is basically another folder in app codebase and i and other devs are free to explore it /commit in it.

    regarding the peer reviews, our peer reviews are non existant. we go throught the PR and point out usual stuff like move strings to constants , use xyz function instead of abc function etc.

    their PRs also got merged like this only. they would make PRs with 200 file changes and we won't bother going through them coz who would have thought that this feature will eventually come to us with this bad handover
  • 2
    manager is telling you to own it as an opportunity to become more important to the company

    he's a manager so he doesn't know the details, he is just giving you political advice. you can take it as a suggestion

    at least I hope that's what's going on

    you seem pretty smart though. you feel overwhelmed. but your thoughts consider more things than other people on your team do. this actually correlates to better adaptation ability. I think they understand you have the best chance of wrangling with that module than anyone else because you notice such small details. you feel overwhelmed by it, but your co workers feel overwhelmed at your questions themselves, which are simpler than the codebase

    granted it could not be something you want to do or have for your career, I do not know
  • 2
    If you own it, you have the freedom to kill it.
  • 0
    This happens all the time, and what other people are saying is right: It's perfectly valid to declare it as unmaintainable and communicate that the alternatives are to either invest time into fixing it or that it will continue to be a time bandit that easily breaks.

    In my experience, this often comes down to the rest of the team simply not being aware of the state of things. In this case it might even be your responsibility to raise the issue.
Add Comment