Hi Bill,Thanks for your thoughts on communication.My 15 year old son is not doing software development with his online communication tools <g>, but I can see that, at least sometimes, Skype is being used to maintain focus on goals, even if they are goals in the video game. All my very best,Rob -- Rob Echlin, B. Eng. 613-266-8311 - Ottawa, ON http://talksoftware.wordpress.com - http://picasaweb.google.com/coderoller On Thursday, May 14, 2015 6:18 PM, Bill Strosberg <oclug [ at ] strosberg [ dot ] com> wrote: On 15-05-06 06:45 AM, Robert P. J. Day wrote: > yet another process-oriented question about git ... not long ago, i > was teaching a 1-day intro git course and, early on, one of the > students mentioned that one problem they were having with their > current VCS was too many people trying to check in changes and > stepping on each others' toes and causing conflicts, and how did git > solve that? > > i briefly mentioned git's merging ability and so on and so on but, > in the end, i said that no tool was going to solve that; what she was > talking about was a workflow issue that could only be solved by their > developers *communicating* with each other; that is, *talking* about > what parts of the code base they were working on so they didn't keep > bumping into one another. and i emphasized that no level of > sophistication of a VCS could replace developers talking to each > other. > > i didn't think that was such a controversial position, but she did > *not* take kindly to that. we were only about a half hour into the > course, and she was already preparing to dislike git because of what > she understood as its first major failing. i stuck to my guns, though, > and by the end of the day, once she had a better understanding of git, > she seemed a lot happier so, crisis averted. > > but, was i wrong? the position i took was that, regardless of the > sophistication of your VCS, if you are *constantly* fighting with > merge conflicts, then the problem is not with the VCS but with your > team's workflow. and since git was a distributed VCS, that actually > had the potential for making things worse since there was (typically) > no concept of an exclusive check out that prevented others from > working in the same area. > > i did suggest that there were alternatives. one i proposed was that > all changes to the code had to relate to an existing ticket in a > ticket system, and that developers should be required to (exclusively) > check out the ticket to work on it. > > but, in the end, what are others' thoughts on this? > > rday > Robert: You appear to have hit the nail on the head in regards to development projects that suffer from fragmentation and loss of focus. Communication IS key, and tools are only as good as the team using them. I've run companies and development teams during my career and I quickly learned that adding people and reducing communication effectiveness is the quickest way to fail to get projects completed on time and on budget. I've been surprised recently by my 16 year old son (of all people) - he's involved in gaming development - and I've been shocked at how well they use Teamspeak and team communications across time zones and geography. His initial exposure to Teamspeak was as an enhancement to the gaming experience - players could trashtalk and make fundamentally solitary remote games into a vibrant social communication arena (and learn new ways to "express" themselves in other languages). This is a change from my mentality in that development communication has always been face to face, structured and somewhat formal and scheduled. I've listened to his team meetings and they are far better at communicating and using the social aspect of team dynamics to keep things focused and control/eliminate work outside the group project goals. They use the social pressure of group meetings on Teamspeak to handle the role of who does what, what changes are important and priority maintenance. There does not seem to be the need for top down hierarchical manager-driven control - the society of the group handles things quite well and effectively. Getting things back in focus, git is one tool that needs to be implement in concert with other necessary project tools to be effective. Although a VCS is an important element, it is perhaps less important than using other tools to help manage today's complex, distributed development environments that may span time zones, cultures and languages. It seems making team communication a positive rewarding social meeting place has more of an effect on things than I ever thought it would. -- Bill _______________________________________________ Linux mailing list Linux [ at ] lists [ dot ] oclug [ dot ] on [ dot ] ca http://oclug.on.ca/mailman/listinfo/linux