3 ms·
Our company's full-time job is to shrink our customer's codebase size aggressively. Your team will not do that because it's a job security to them. Let us make
by xstartup 9y ago
Our company's full-time job is to shrink our customer's codebase size aggressively. Your team will not do that because it's a job security to them. Let us make your company where it's easy to fire anyone without risking major drawdowns.
- HumanDrivenDev 9y agoSo you're with a consulting company specialising in refactoring!? How do you sell that to people?
- xamuel 9y ago>Your team will not do that because it's a job security to them Every team I've ever been on [albeit that's only two], it's the opposite, if the devs had their way they'd spend all day every day simplifying and refactoring. The only reason we don't, is because actual business needs demand attention.
- sooheon 9y agoAgreed. Putting out fires sadly takes precedence over future fireproofing.
- psyc 9y agoProcess/policy often prohibits refactoring for its own sake. I've always got round this by rewriting everything 5 times before checking it in for the first time.
- dingo_bat 9y agoIf I had a free reign over my time at the office, I'd spend at least a month just cleaning up the mess that has accumulated.
- flukus 9y ago> Our company's full-time job is to shrink our customer's codebase size aggressively. Your team will not do that because it's a job security to them. No, they did do that, that's where the layers of bloat originated from. Everything turns out to be not quite as generic as the authors thought and that helper function end up as it's own class with an inheritance tree, etc. That fancy mapper that uses reflection to eliminate hundreds of lines of boilerplate becomes a liability because information is now lost to future maintainers. I don't want less code, I want simple, greppable code that allows me to trace data across the codebase.