Questions to ask oneself '''before''' deciding to join a new project 1. Who will be managing this project? 1. What is the status/the availability of the programmer you are pairing with (if you are doing pair programming): is he single/married etc. Will he be capable of working on the project without causing friction with a significant other or with many significant others? (1) (2) 1. Is this project worth doing? (Many or even most are not) 1. Is the salary or the % worthwile? 1. Is the final product an original software or is it an exact copy of similar software? 1. Do I want to work on it? 1. Are the other people working on it good to work with? 1. Will I bring value to the project by being a part of it? 1. Is the time frame for this project short enough to keep up interest and enthusiasm? 1. Does this project have a high potential for success? 1. Will I be better qualified for future projects when I complete this one? 1. What is the likelihood that on completion of this project, other interesting work will be available? ----- Notes: (1) This is very delicate situation. As 63.167.142.27 has pointed out below, when a programmer works too long on a project, the family might object and this can cause tremendous friction in a working relationship thus killing a project. So we are walking on eggs here and one has to be pretty careful... Checking the programmer's status and availability would be an excellent precaution to take before embarking on a project with him. (2) '''The flip side of the coin''' Be careful... "possessive" often means "resents having a family member stolen away from them for long hours", and rightfully so. ---- ---- '''Questions to ask oneself when entering any new software project''' ---- '''Management, Code Repository, Tests, Databases, ContinuousIntegration, StagingServer, TaskDatabase''' 1. Do I have one and only one boss? 1. What are the objectives of my new position? Why did the original developer leave? 1. Who are the team leaders of the different modules? 1. Is there a revision control server (CVS or another VersionControlSystem) where the code is being stored? 1. Are automated tests being stored in the same revision control server where the code is being stored? This is needed only simplifying the testing and making sure that the correct bits are being tested with the right bits. 1. Are automated database scripts being stored in the same revision control server where the code is being stored? 1. Are there independent databases for each developer, so that each developer may create the database from the scripts in revision control? 1. Is there an IntegrationServer that performs daily builds to verify that the code revision control still compiles and that all automated tests still pass? 1. Is there an implementation plan in a TaskDatabase? In XP the implementation plan is called ReleasePlan. 1. Is there a CodingConvention document in revision control? 1. Are there user manuals in revision control for each of the modules? 1. Is there a StagingServer that allows to perform ManualTests on what is being implemented according to the user manuals? 1. Is there anything already implemented that is manually testable, even if it is just doing login/logout and navigating the menus? 1. Is it clear what has been accomplished and what is pending? -- GuillermoSchwarz '''Humorous''' 1. Is there a guy making a myopic list of things to ask? 1. Where is the restroom? ----- '''Comments''' This all seems to revolve around revision control, which is a bit narrow of a focus considering the page name. ''[Critique of CVS moved to ConcurrentVersionsSystem.]'' The questions asking if two things reside on the same server are completely opaque. Who cares which servers things are on? That should be transparent. Oh, it's not? Then '''that's''' what should be addressed above. * The important thing is that all can be compiled and run at once. Also it is important that all are given the same build number. It is easier to avoid messing things up if they are on the same server. Besides 40GB disks are cheap now. ---- '''Re: the book Software Project Survival Guide''' The book SoftwareProjectSurvivalGuide is essentially an expanded version of checklists like this. ''Is it a good book? I'd like to recommend it to someone if you think it is. I see on Amazon that it got pretty mixed reviews, but one of the positive ones was from Tom Duff, which initially would seem to outweigh the negative reviews.'' It is indeed a good book. Also RapidDevelopment is a good book. -- GuillermoSchwarz ''I suppose I'll have to provide the other half of "mixed". It's good, if you subscribe to the exact methodology the author does. But that's the point of the book: RapidDevelopment give a survey of common development practices; SPSG gives one possible combination of good practices that should, in the author's opinion, work more often then not. But it's no more than that. --TimLesher'' ---- See QuestionsForParticipationInaNewProject ---- CategoryManagement