Philip Oakley <philipoakley@iee.email> writes: Hi Philip,
> How independent are the teams - when do you even find out they exist? They know each other and at least have a vague idea about what the others are doing. But since many development topics are cross-cutting, it's hard to tell if you and they will stomp on each others' toas. > How well is the code structured? If it's corporate code then behind > the branding and PR will be a Big Ball of Mud of code that's barely > keeping its head above water for purity (etc). i.e. as a general > observation, it's almost always doomed by cost and schedule ;-) I have nothing to add. ;-) (Ok, it's not that bad but surely shows signs of many of your arguments and age.) >> So the (rhetorical) question is: could the developer in step 1 have >> known beforehand that his changes are going to cause such troubles so >> that instead of doing a major refactoring he would just do the most >> minimal change fixing the bug? > Ah, the big ball of mud minimalism problem - touch as little as > possible, it's all booby trapped, especially if it also old. No, not really. It's the "ensure no two persons refactor the very same code in parallel" problem. >> I guess, the question is "yes" because the required information is there >> for sure. > > It's mainly a social/management problem about mutual communication and > the wider team spirit. > - make sure you know hat other projects are going on and Sure, but that's usually more a birds-eye view which is not enough for a concrete technical question. > - get some visibility of the areas they are 'playing' in (working on) Bye, Tassilo -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/87h7pndluk.fsf%40gnu.org.