On Jan 22, 2008 2:40 AM, Ronald Wiplinger <[EMAIL PROTECTED]> wrote: > What is a good tool to coordinate a team of programmers efficiently?
that is a big question, primarily because there are many facets of coordination with different tools to help out. obviously version control is one of the fundamental tools of this coordination. it lets you do things like maintain 'versions' of your software. there are many ways to leverage this concept. development version vs production version; customerA version vs. customerB version and so on. there is also the nice aspect where multiple developers can work on the same file simultaneously. any one of the standard tools (others have already mentioned) cvs, svn, git will have literature on basic usage of the software and the underlying concepts. in general though i think the question of managing efficiently is not the greatest perspective. i would instead focus on managing 'effectively', see the 7 habits of highly effective people. and its still somewhat of an art in the end. To give each one a different part of the project is a start, but it needs to > get combined at some points to be a working project. here you are getting into several potential topics as well. so, the main thing here is dependencies. say 2 developers are given a number of 'components' to work on. pretty simple right, look at the requirements, devA gets tasks 1-4, devB gets tasks 5-8; no problem. what you need to consider here are the relationships between the tasks, in particular, are any of tasks 5-8 dependent upon any of tasks 1-4? if so, then devB could end up having to wait for devA to complete a dependent task before progress on said dependent task is possible. your decision here can also have an impact on the design of the software as a whole. see, organizing the tasks in such a way that there are no dependencies in the tasks devA and devB have (or next to none anyway) then you will get a high degree of throughput, because they can both be working on completing different objectives simultaneously; its sort of like threading. i am of the opinion however, that this can get you some poorly designed software. the developers may not be leveraging the strengths and covering the weaknesses of each other. furthermore, its ideal to divide software into horizontal layers rather than vertical towers. its more complicated, but you have a better product as a result. so anyway this topic is a big overall decision. > Not to debug code you have written was a hint, to see actually bugs as a > bug > and not as a feature. obviously you will have to debug code you write that isnt working. generally, functionality is perceived as 'features' near the beginning of a development cycle, and as 'bugs' towards the release of a development cycle. watch out for deeming everything as a bug, because then youll get trapped in a horrible realm where you only implement functionality to fix these 'bugs'. you should have a cycle with well defined phases and stick to it. one important phase is after a major release, you need to go through the code, re-organize it, consolidate things and remove the dust. this will keep you in good shape for the next round of features (if you perceive them as such ;)) > Some hinted let programmer be on different places, others say put them > together on a big table, ... probly you should start small with everyone at the same location until you have the basics down. > Where can I find more information about that subject? > check out the mythical man month if you get a chance. its a short book that is generally considered as legendary. its been recommended to me by 2 completely unrelated millionaires and the dude who wrote the Solar framework; basically, its key ;) (but it wont help you to master any of these modern tools) -nathan
