3 ms·
Good point. I guess it boils down to team size. If the team size is large then the code is more likely to be refactored in stages than rewritten. And more peopl
by davidhyde 9y ago
Good point. I guess it boils down to team size. If the team size is large then the code is more likely to be refactored in stages than rewritten. And more people on a team usually means more code reading than writing. Also, you have a higher turnover of people so onboarding cost is important.
Small team size means you don't have a lot of these problems.
- mirko22 9y agonot necessarily, 50-100 person team in random bank for example can’t even do all of the tickets they should in whatever timeframe they have less alone refactor something properly, and not cos they are busy, but for variety of other reasons, one of them being turnover. this has a lot to do with how your code looks to begin with, bad code is generally hard to refactor, and refactoring is not a cure for bad code.
- toss1 9y agogood pint about team size. I'd think it may not apply so much with huge teams, as if you probably need to have a very extensive definition of the problem to justify a large team at the outset, so doing the long-term architecture & design up-front (vs. a throw-away version) would likely be best. I'd hope for a situation where the initial small team built the throw-away, ran it hard, then use that knowledge to build the big version and the big team.