Team Formation

Dr. Tallman

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.

Team Formation & Performance

ECE 297

Four Stages of a Team

• By Bruce Tuckman, Psychology Professor

1. Forming– Picking team, getting to know each other

2. Storming– Figuring out who does what & how, often contentious

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

You are here!

Want to get here (or beyond)

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

f1.cpp f2.cpp

builds

testsprog.exe

builds

testsprog.exe

svn update

svn commit

Features Not Totally Independent?

Feature 1 Feature 2

f1.cpp f2.cpp

builds

testsprog.exe

builds

testsprog.exe

svn update

svn commit

common

CommonMore communication

during planning & coding

common

Frequent commits more important.

Continuous integration!

Coding Routine

1. svn update to latest code

2. fix a bug, or enhance a feature, or …

3. build

4. test

5. svn commitWhat if someone else changed repository code?

svn updatebuildtestthen 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

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

image: llewellynfalco.blogspot.com

Project Management

Waterfall Development

• Up front planning• Phases: concept to detailed implementation• Motivation: early changes cheaper

Changes cheap

Changes expensive

Does not really work for complex projects no one can plan

well enough!

Iterative/Agile Development

Test & Evaluate

Refine

Prototype

Includes end-user / customer evaluation

Plan, but quicklyLater parts of the plan more coarse

One Flavour of “Agile”: Scrum

• Choose features for 21-day sprint• Team meets each day for 15 min scrum• End of each sprint working SW for customer

image: ecomcanada.org

21

Big Projects

• Altera:

• 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

+$200 M

State of the art for 2 years!

22

Project Management: Schedule

Work Completed vs. Time

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

0% 20% 40% 60% 80% 100%

Project Time Elapsed

Pro

jec

t C

om

ple

tio

n No Milestones

Milestones

23

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

Can be HW + SW

Case Study:Case Study:

25

BackgroundBackground

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

26

Place and Route ExamplePlace and Route Example

27

Managing ComplexityManaging 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

28

Design: Limit Scope!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”

29

Project ManagementProject 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

30

Measure Something QuantitativeMeasure 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”

OutcomeOutcome

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)Case Study: Quartus (First Version)

33

BackgroundBackground

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

34

ComplexityComplexity

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

35

Planning and PrototypingPlanning and Prototyping

No working prototype for much of the project Spent a year planning, with no coding

- Too much Waterfall paralysis

36

Scheduling & MeasuringScheduling & 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

37

OutcomeOutcome

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!

Case Study: Parallel PlacementCase Study: Parallel Placement

38

39

The FPGA Compile Time ChallengeThe FPGA Compile Time Challenge

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

(CPU speed)

40

Parallel BackgroundParallel 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 ApproachThe 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

ResultsResults

~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