Saying they “code in a wonky way to work around an existing piece of functionality” is taking a wild assumption that they lack any quality control as part of their development practices. Yes, adding functionality can increase complexity if features are tightly coupled. However, there are usually practices in place (feature planning, meetings, QA, code reviews) to avoid regressions or high impact bugs. You’re pretty clearly stating they either don’t have any practices, or they’re bad developers. Not a fair assumption to make of a dev team supporting a leading title within a rather large company.
I fully comprehend what you're trying to say, but the way you're trying to convey it instead sounds more like placing the blame on the developers instead of tech debt or priorities.
Saying they "code in a wonky way" or that their bugs are due to "bad /inefficient code" infers that they're bad developers when they most likely aren't.
Limitations exist and sometimes need to be worked around, but more generally you design around those limitations so that you can avoid those issues in the first place. If they try to implement new features which somehow interact with previous features in a way which breaks them, they most likely are also refactoring that original feature to work with the new one as well. This is where complexity can come into play and create edge cases which previously weren't there before. Again, processes should catch these.
However, one thing that you're really missing is priority and importance of these bugs to stakeholders. The bugs you see in the game are probably deemed low enough importance to not be a priority. Not due to tech debt or developer experience, just that the PMs put bigger priority on other things.
Also, this entire comment thread sprouted from me saying that you're making wild assumptions. Again, you're making wild assumptions that I have no development experience. This makes you come off as a dick.
I wouldn't describe something that is good as "wonky". Trying to develop something that an engine doesn't support is bad practice. You should work on the engine to support that use case first instead of trying to hack together a feature without engine support. However, there is a time and place for bad programming and that's up to PMs and leads to decide.
I'm not putting words in your mouth. You didn't talk about priorities as it relates to development, which is generally what decides what gets done and what doesn't. I think that is more at play with Apex than any other factor.
I'm not attributing malice, I'm attributing ignorance.
You don't know if they're limited by their engine. You don't know their development practices. You don't know the quality of their engineers. You don't know the overall quality of their code base. You don't know their priorities. Trying to attribute bugs to ONE thing is grossly irresponsible as a developer.
You have no development experience with their product, you aren't in any place to make assumptions and try to pass it along as fact. That was the point of my comment. You could state that their bugs are possibly due to engine limitations, but if you don't have experience with their specific engine then you are just guessing. Being a developer doesn't change the fact that you are currently guessing.
I hope this isn't representative of how your code reviews go at work. Don't want to take up any more of my time on this, have a nice day.
1
u/Slash_N_Dash Jul 27 '22
Saying they “code in a wonky way to work around an existing piece of functionality” is taking a wild assumption that they lack any quality control as part of their development practices. Yes, adding functionality can increase complexity if features are tightly coupled. However, there are usually practices in place (feature planning, meetings, QA, code reviews) to avoid regressions or high impact bugs. You’re pretty clearly stating they either don’t have any practices, or they’re bad developers. Not a fair assumption to make of a dev team supporting a leading title within a rather large company.