Team Formation

1
Team Formation

• Dr. Tallman

2
ECE297 Tutorials, Jan 21 Jan 23

• Your team will meet your Communication Instructor
  (CI) and schedule a weekly 30-minute 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.

3
Team Formation Performance

• ECE 297

4
Four Stages of a Team

• By Bruce Tuckman, Psychology Professor
• Forming
• Picking team, getting to know each other
• Storming
• Figuring out who does what how, often
  contentious
• Norming
• Team has figured out who does what, members
  understand and accountable for their roles
• Performing
• Only high-performance teams reach this stage
  continuous improvement, open discussion, high
  trust

You are here!
Want to get here (or beyond)
5
High-Performing Teams

• Open discussion
• Tell it like it is!
• Dont let things fester
• But be constructive
• Transparency
• If youre behind or some of your code doesnt
  work, say so clearly
• Dont 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!)

6
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 TAs expertise
• Mentors are valuable ? ask questions

7
Team wiki

• Teams memory and to-do list
• Key data
• Whats done
• Whats 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

8
Coding in a Team
9
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
10
1. Split Up Functionality

• Work in different files or functions

Feature 1
Feature 2
svn update
f1.cpp
f2.cpp
builds
builds
tests
tests
svn commit
11
Features Not Totally Independent?
More communication during planning coding
Common
Feature 1
Feature 2
svn update
common
common
f1.cpp
f2.cpp
builds
builds
tests
tests
svn commit
Frequent commits more important. Continuous
integration!
12
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
13
Update/Commit Often

• Continuous integration
• Otherwise can run out of time at the end
• Easier to move tasks between team members
• Dont have a lot of new code in one team members
  working copy only
• But dont break the build
• Do not commit broken code
• Wont compile
• Or breaks previously working tests
• Halts development by other team members

14
2. Split Development and Test

• Test debug is massively parallel
• Can add many people, even late in project, and
  get gains

Testing Debugging
Developing new features
15
3. Pair Programming

• One computer, two programmers
• Driver
• Writing code
• Focus on details
• Navigator
• Reading code, giving feedback
• Focus on strategy What if theres a NULL ptr?
• Switch roles frequently
• Talk a lot
• Stop when you get tired
• Pair Programming Tutorial

16
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
17
Project Management
18
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

19
Iterative/Agile Development
Plan, but quickly Later parts of the plan more
coarse
Prototype
Refine
Test Evaluate
Includes end-user / customer evaluation
20
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

21
Big Projects

• Altera
• Plan as far ahead as you can, but dont 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

200 M State of the art for 2 years!

22
Project Management Schedule
23
Design Prototype Early

• Not having a working system is very dangerous
• Dont know when/if the system will work
• Engineers cant test their work in the whole
  system
• Dont 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

Can be HW SW
24
Case Study
25
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 Alteras chips
• Aggressive goal 10X better than current system

26
Place and Route Example
27
Managing Complexity

• Have 25,000 lines of C code
• Dont target Alteras 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

28
Design Limit Scope!

• Stick with C
• Project already complex, full of uncertainties,
  tight schedule
• Dont add more complexity and work
• Not right time to become expert in new language
• Customer doesnt 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

29
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 didnt get paid by Altera
• Schedule milestones were crucial ? focus

30
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
• 3 numbers made it clear where we stood at all
  times
• Everyone measured on all important changes
• You cannot improve what you cannot measure

31
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 ? didnt need more!

32
Case Study Quartus (First Version)
33
Background

• Altera had highly successful CAD system
  MaxPlusII
• 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

34
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
• Hadnt defined how to measure these features
  either

35
Planning and Prototyping

• No working prototype for much of the project
• Spent a year planning, with no coding
• Too much Waterfall ? paralysis

36
Scheduling Measuring

• Schedules repeatedly missed
• Task list not detailed enough
• Too much complexity
• Didnt 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

37
Outcome

• Software not ready in time for chip
• Software rushed to market
• Not stable enough, didnt optimize well enough
• Very bad customer experiences
• Lost sales billions!
• Rewrote renamed later versions
• Now very good!

38
Case Study Parallel Placement
39
The FPGA Compile Time Challenge
(CPU speed)

• Chip size growing more rapidly than CPU speed
• How to keep CAD tool runtime under control?

40
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

41
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

42
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