1. Sample Wiki
Comments?

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

3. 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

4. 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

5. 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

6. Coding in a Team

7. 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

8. 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

9. 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!

10. 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

11. 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

12. 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

13. 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

14. 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

15. Project Management

16. 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

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

18. 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

19. 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

20. Set Measurable Milestones
Key to keeping larger projects on track