Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
At the time, it should have been raised to an independent manager, outside both teams, and they should have decided which way to go.
Unless something's changed, I wouldn't bother trying to clean it up. Whoever allowed that situation to happen in the first place is just going to allow it to happen again, and then they'll assume it'll be fine because some poor sod will just clear up the mess afterwards. -
@AlmondSauce I disagree, this is clear technical debt and should be on somebody's backlog to sort it. The sooner the better as the longer you're maintaining two repos the harder it will be.
Difficult to advise a solution to the politics as I don't understand the view point of either problem party. Why does your Senior not want the features and why did the other team want to use a separate issue.
Surely now the features exist it's at least easier for them to have a conversation about where they should be maintained -
@LMagnus
We have the two repos anyways, that's not an issue.
The people on my team said "we don't want to have to maintain these features forever without discussing things first" and the other team said "we need these now so we're adding them to our repo if you guys wont let us put them in yours".
I think now i might be able to talk the team into cleaning this up (bringing everything related to this to our repo) because the features have been used for 2 years. -
My question being why you don't use std::vector?
The standard implementation of this is surely more efficient than whatever your poorly standardized (throughout your own company!) implementation is. No offense.
Not only that, but std::vector will be directly accepted by many libraries whereas your own implementation would not.
Therefore, I recommend pushing for use of std::vector in the meeting when you bring this issue up. -
@AlgoRythm
Not enough control of how std::vector allocates memory.
Even if our implementation isn't the most efficient (it's pretty good though), the fact that we have complete control over how it allocates memory basically overrules everything else.
Regarding the fact that other libraries won't except our version: it doesn't matter because we don't use any other libraries. -
@YADU Well, it always depends on the project needs. In general case I would recommend using std implementations but in your case, for example, I would not. I'm assuming you're in a pretty limited environment where resources are coveted.
However, I can ALWAYS recommend a standard codebase. -
@AlgoRythm
We do a library that's embedded. Memory is more of a concern than performance in most of our code.
Our users bitch about us so much as heap allocating anything so we have to be fairly careful.
I completely agree with you about preferring the STL in almost all cases though.
Best way to deal with office politics?
As background: we have our own implementation of some C++ data structures, including an "Array" class (basically the same as std::vector).
A few years ago, the senior guys on my team refused to add new features to it for (seemingly) no good reason.
So senior guys from another team added the features anyways, in THEIR repo.
My team couldn't stop them, but refused to allow the new features in OUR repo, so now our Array is split between two repos for no good reason 😢.
Two years later, here I am, hoping to clean this up. As far as anyone knows, there's no good reason to have it split up like this.
How do i convince my team that we should move the code to OUR repo where it belongs?
question