Sample Wiki Comments?

Wiki: Try #2 Measurable milestones, with owners & target dates

Partner Broke Build Ken, The build is broken; can you take a look? Vaughn No sense of urgency & action required is vague Not very specific & not clear it is Ken’s problem Ken, Once again you broke the build! Sadegh and I can’t work – this is unacceptable. Fix it now! Still no evidence it is Ken’s problem Conveys urgency & asks for specific action Tone: angry and condescending  will damage relationship

Partner Broke Build? Specific problem and evidence it is Ken’s Hi Ken, There are many compilation errors in streets.cpp. The last commit to this file was at 8 pm last night by you so we think it’s your code. This is holding Sadegh and I up (can’t compile). Can you take a look ASAP, and also let us know when you can fix this? If it can’t be fixed in the next hour, we’ll have to revert your changes. Thanks, Vaughn Conveys urgency, asks for specific action and sets a time limit Tone: respectful & polite, but firm

Conflict E.g. Partner not meeting commitments? Talk about it! What would you do? Talk about it! In person Be factual, not emotional Likely have to talk multiple times Write down the outcome on the wiki Less aggressive commitments? Or more commitment & tracking? Talk to TA and/or CI? Yes, if not resolved But be sure you have told teammate issue first Hurts trust otherwise, and reduces your learning

Coding in a Team

Coding Productively in a Team Want Parallel development  multiple team members working at once Without wasting work or blocking each other How? “Adding manpower to a late software project makes it later.” -- Fred Brooks

1. Split Up Functionality Work in different files or functions Feature 1 Feature 2 svn update f1.cpp f2.cpp builds builds prog.exe prog.exe tests tests svn commit

Features Not Totally Independent? More communication during planning & coding Feature 1 Common Feature 2 svn update f1.cpp common common f2.cpp builds builds prog.exe prog.exe tests tests svn commit Frequent commits more important. Continuous integration!

Coding Routine svn update to latest code fix a bug, or enhance a feature, or … build test svn commit What if someone else changed repository code? svn update build test then re-try svn commit

Update/Commit Often Continuous integration Otherwise can run out of time at the end Easier to move tasks between team members Don’t have a lot of new code in one team member’s working copy only But don’t break the build Do not commit broken code Won’t compile Or breaks previously working tests Halts development by other team members

2. Split Development and Test Test & debug is massively parallel Can add many people, even late in project, and get gains Developing new features Testing & Debugging

3. Pair Programming One computer, two programmers Driver: Navigator: Writing code Focus on details Navigator: Reading code, giving feedback Focus on strategy: “What if there’s a NULL ptr”? Switch roles frequently Should each have some svn commits Talk a lot Stop when you get tired Pair Programming Tutorial

Pair Programming Two people writing one thing: productive? Less code written But higher quality Saves debugging & future issues Helps a team become cohesive Grows expertise of team members  mentoring Helps team members read each others code Most studies say more productive for new teams, and/or one programmer not expert image: llewellynfalco.blogspot.com

Project Management

Option 1: Waterfall Development Changes cheap Does not really work for complex projects  no one can plan well enough! Changes expensive Up front planning Phases: concept to detailed implementation Motivation: early changes cheaper

Option 2: Iterative/Agile Development Plan, but quickly Later parts of the plan more coarse Prototype Refine Test & Evaluate Includes end-user / customer evaluation

One Flavour of “Agile”: Scrum image: ecomcanada.org Choose features for 21-day sprint Team meets each day for 15 min scrum End of each sprint  working SW for customer

Agile: Prototype Early Not having a working system is very dangerous Don’t know when/if the system will work Engineers can’t test their work in the whole system Don’t know where the problem areas to improve / optimize will be Get something simple working Test & Measure Add features / Improve problem areas Repeat Keep it simple! Use simplest approach that works

Set Measurable Milestones Key to keeping larger projects on track