Team Formation
Dr. Tallman
ECE297 Tutorials, Jan 21 & Jan 23
• Your team will meet your Communication
Instructor (CI) and schedule a weekly 30minute meeting beginning the following week.
• Wed, Jan 21, 1-3pm, students go to GB404
• Fri, Jan 23, 9-11am, students go to GB412
• Fri, Jan 23, 3-5pm, students go to GB412
• If you do not have a full team formed by these
dates, come to your scheduled tutorial, and
Dr. Tallman will assist you.
Team Formation &
Performance
ECE 297
Four Stages of a Team
• By Bruce Tuckman, Psychology Professor
You are here!
1. Forming
– Picking team, getting to know each other
2. Storming
– Figuring out who does what & how, often contentious
3. Norming
Want to get here (or beyond)
– Team has figured out who does what, members
understand and accountable for their roles
4. Performing
– Only high-performance teams reach this stage;
continuous improvement, open discussion, high trust
High-Performing Teams
• Open discussion
– Tell it like it is!
– Don’t let things fester
– But be constructive
• Transparency
– If you’re behind or some of your code doesn’t work,
say so clearly
– Don’t hide or evade
• Accountability
– Take responsibility for your part of the project
– Own your mistakes, delays, etc. and find a solution
• Trust
– Helped by all the above
– Plus spend time working together (in person!)
Team Status Meeting
• Two per week: 1 with CI & 1 with TA
– Typical industry practice: weekly team meeting
– With written status (usually wiki)
– Good meetings help make good teams
• Show transparency and accountability
– Concise statement of what is done and not done
– Clear (single person) ownership of various tasks
• With a target completion date
• Leverage the CI & TA’s expertise
– Mentors are valuable  ask questions
Team wiki
• Team’s memory and to-do list
– Key data
– What’s done
– What’s next
• Can have lots of detailed data
– If so, add a summary for weekly CI & TA meeting
• Should have email with initial password
– Change it!
• Your wiki: for your team, TA and CI
• Wiki Quick Start Guide
• Go to 297 wiki
Coding in a Team
Coding Productively in a Team
• Want
– Parallel development  multiple team
members working at once
– Without getting in each others way / wasting
work
• 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
f2.cpp
f1.cpp
builds
prog.exe
builds
tests
svn commit
prog.exe
tests
Features Not Totally Independent?
Feature 1
More communication
during planning &
coding
Common Feature 2
svn update
f1.cpp common
builds
prog.exe
f2.cpp common
builds
tests
svn commit
Frequent commits
more important.
Continuous integration!
prog.exe
tests
Coding Routine
1.
2.
3.
4.
5.
svn update to latest code
fix a bug, or enhance a feature, or …
build
test
What if someone else
changed repository code?
svn commit
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:
• Writing code
• Focus on details
– Navigator:
• Reading code, giving feedback
• Focus on strategy: “What if there’s a NULL ptr”?
– Switch roles frequently
– Talk a lot
– Stop when you get tired
• Pair Programming Tutorial
Pair Programming
• Two people writing one thing: productive?
1. Less code written
• But higher quality
• Saves debugging & future issues
image: llewellynfalco.blogspot.com
2. Helps a team become cohesive
3. Grows expertise of team members  mentoring
4. Helps team members read each others code
• Most studies say more productive for new
teams, and/or one programmer not expert
Project Management
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
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
Big Projects
• Altera:
+
$200 M
State of the art
for 2 years!
• Plan as far ahead as you can, but don’t paralyze yourself
– Plan gets coarse as you go out in time
• Have measurable milestones
–
–
–
–
3 year project  need to break up schedule
Hold people to these milestones!
Clear must have features
Everything else: nice to have
• Get something working and improve  still iterative
– Define quantitative metrics, and measure constantly
• Weekly status meeting
– wiki, crisp reporting
– Big picture  progress toward milestones
21
Project Management: Schedule
Work Completed vs. Time
Project Completion
100%
90%
80%
No Milestones
Milestones
70%
60%
50%
40%
30%
20%
10%
0%
0%
20%
40%
60%
Project Time Elapsed
22
80%
100%
Design: 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
23
Can be HW + SW
Case Study:
Background




My PhD thesis: new CAD System for FPGAs
Results best published to date
Commercial interest
Formed company to commercialize
 4 people initially

First customer was Altera
 10 months to produce a new placement and routing system for
Altera’s chips
 Aggressive goal: 10X better than current system
25
Place and Route Example
26
Managing Complexity

Have: 25,000 lines of C code
 Don’t target Altera’s chips or deal with full complexities of
commercial chips
 Have to write a lot more code

Maybe C++ would be better long-term?
 If we re-write now, much easier than re-writing later
 But, extra work and we had more experience in C
27
Design: Limit Scope!

Stick with C
 Project already complex, full of uncertainties, tight schedule
 Don’t add more complexity and work
 Not right time to become expert in new language
 Customer doesn’t care what language we use: wants better placement
and routing results

Solve the problems you need to, and skip the rest

Several companies have destroyed themselves trying to
move to the “next big programming language”
28
Project Management

Created fairly detailed schedule
 What would each person work on
 How long would each task take
 Added 50% extra time for each task for problems / unknowns
 Defined measurable milestones
 Every 3 months, we had a specific test to show more of the project
worked
 Otherwise we didn’t get paid by Altera
 Schedule & milestones were crucial  focus
29
Measure Something Quantitative


Best way to spiral and track a project: measure
Define quantitative metrics
 Then measure them throughout the project

Right Track CAD: measured
 Circuit Speed
 Compile Time
 Fraction of circuits that completed


30
3 numbers made it clear where we stood at all times
Everyone measured on all important changes
“You cannot improve what you cannot measure”
Outcome

Hit all milestones, except first (2 weeks late)
 Focused!

CAD system exceeded expectations
 30X less runtime
 38% faster circuits
 Altera replaced their P & R engine with the prototype

Started simple, measured where to improve
 Some simple algorithms still in current Quartus II  didn’t need
more!
31
Case Study: Quartus (First
Version)
Background


Altera had highly successful CAD system:
Max+PlusII
Decided to do a complete re-write to a new CAD
system
 Quartus
 Started ~1995 - 1996

Goals:
 C++ (not C)
 Cleaner, more extensible code
 Allow multiple engineers to collaborate on a project easily
 Allow fast, “incremental” recompiles
33
Complexity

Quartus was complex
 Re-write of multi-million line software system
 New language (C++), engineers not as familiar with it
 Object-oriented design became a goal
 Features that no one knew exactly how to implement (incremental
recompile, workgroup computing) were considered key
 Hadn’t defined how to measure these features either
34
Planning and Prototyping


No working prototype for much of the project
Spent a year planning, with no coding
 Too much Waterfall  paralysis
35
Scheduling & Measuring

Schedules repeatedly missed
 Task list not detailed enough
 Too much complexity

Didn’t see lateness and scale back soon enough
 Lack of clear milestones
 Not measuring quantitative metrics toward the real goal

True key goal:
 Stable CAD system that optimized well
 Ready for the next chip (APEX 20K) when silicon available
 Everything else secondary
36
Outcome


Software not ready in time for chip
Software rushed to market
 Not stable enough, didn’t optimize well enough
 Very bad customer experiences


Lost sales: $billions!
Rewrote & renamed later versions:
 Now very good!
37
Case Study: Parallel
Placement
38
The FPGA Compile Time Challenge
(CPU speed)


39
Chip size growing more rapidly than CPU speed
How to keep CAD tool runtime under control?
Parallel Background

1 million line placement & routing system
 Complex algorithms & code
 Excellent quality results
 Need to add new features & chips regularly

Academic parallel placement work
 Mostly non-deterministic (results change every run)
 Much simpler algorithms
40
The Approach


Keep it simple!
Minimize code to make parallel



Measure to find key code
10,000 lines of code out of 1 million
Use very few parallel primitives
 Threads, mutexes

Must be deterministic
 No race conditions; always get same answer
 Much easier to debug & test

Leverage tools
 Dynamic: Intel thread checker
 Static: wrote tool to find thread-unsafe code
41
Results

~4X speed-up on 8 CPUs
 Stable: ~2 customer bugs, both in first 2 releases

Another parallel effort at Altera (timing engine)
 Created rich set of APIs first
 Decided on parallel approach without measuring
 Failed! APIs buggy & parallel approach not fast
42