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 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 1Feature 2 f1.cpp f2.cpp builds tests prog.exe builds tests prog.exe svn update svn commit

Features Not Totally Independent? Feature 1Feature 2 f1.cpp f2.cpp builds tests prog.exe builds tests prog.exe svn update svn commit common Common More 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 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: 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 quickly Later 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

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:

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 Altera’s chips  Aggressive goal: 10X better than current system

26 Place and Route Example

27 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

28 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 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 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”

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)

33 Background Altera had highly successful CAD system: Max+PlusII Decided to do a complete re-write to a new CAD system  Quartus  Started ~ 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 Hadn’t 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 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 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!

Case Study: Parallel Placement 38

39 The FPGA Compile Time Challenge Chip size growing more rapidly than CPU speed How to keep CAD tool runtime under control? (CPU speed)

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