| TBH it really depends on the industry and the nature of the product. Like, even within the same industry consider Video Game A vs. B A) you are making some single player narrative adventure. You don't expect many post launch updates and no DLC plans. You don't really care if the code is spaghetti as long as the core features work: maybe in a potential follow up you clean up a little bit, but not much. The art assets are the biggest factor for reuse. This sounds like the kind of product you work with and while it hurts on an engineering level, I can understand the need to focus more on getting something out than "doing it the right way". But you always have to keep in mind as a company that employees look out for their best interests, too (especially in thei current market). Some employees are fine providing a product, but others may have other aspirations. They may have eyes on another role and saying that they were essentially a scripter isn't good for their velocity. Being able to describe an elegant system they architected and how they improved the performance of a product will be what gets them through their career. B) you are making some multi-player, networked arena battler. You have 2+ years of battle-passes and quarterly character roster/weapon updates. You want to be flexible to provide new modes of battle based on player feedback and be able to quickly rebalance battle systems to ensure nothing ever feels too over/underpowered. Fast iteration times post-launch are a must to properly address this timeline This is where those suggestions from engineering should provide more pause. If you need to move quick 6+ months down the line, maybe those 2 months of re-factoring is worth looking into. Granted, this isn't at all how real multiplayer modern video games work (just throw it all at QA, it's fine), but there should be more discipline in how the code is organized and documented. Especially if you potentially need to hire new talent to ramp up post launch. |