Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One more consideration is whether a team of people have invested time building a mental map of the current code. Perhaps some rearrangement would be better, faster, clearer, or have some other virtue. But that benefit has to be balanced against invalidating the mental caches of all the other team members.

More than once, I've studied code and become adept at maintaining it. Then someone "refactors" everything and I have to invest the effort again. After a few cycles of this, I lose interest in ever seeing the code again. At that point, I can no longer orient a new dev to the code because I'm no longer oriented myself.



Great point about team mental context!

Without knowing the context I would guess that this a bad refactor (away from revealing the intention)... probably including some cases of applying new abstractions that don't fit the real problem. How does that match with your experience?

Update: it occurs to me that I have seen complex code (for which people would need a mental map) be simplified so drastically that no-one needs to worry about mental maps. I would much prefer "no-one needs a mental map" over "there's a team with good mental maps".


That is a pain with new guys on team that don’t want to spend time learning the code but rather rewrite it their way so they can understand it.

Only problem is that’s ultimately not polite to existing team and hopefully we can filter such people in hiring process but not always.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: