LECTURE 11: CODING AS A TEAM CSE 442 Software Engineering Lies, - - PowerPoint PPT Presentation

▶
lecture 11 coding as a team
SMART_READER_LITE
LIVE PREVIEW

LECTURE 11: CODING AS A TEAM CSE 442 Software Engineering Lies, - - PowerPoint PPT Presentation

Mar 12, 2023 255 likes •833 views

LECTURE 11: CODING AS A TEAM CSE 442 Software Engineering Lies, Darned Lies & Metrics Person-year common measure of work performed Work done by 1 person over 1 year 12 people in 1 month also a person-year of work Or 4 people

slide-1
SLIDE 1

LECTURE 11: CODING AS A TEAM

CSE 442 – Software Engineering

slide-2
SLIDE 2

Lies, Darned Lies & Metrics

¨ Person-year common measure of work performed

¤ Work done by 1 person over 1 year ¤ 12 people in 1 month also a person-year of work ¤ Or 4 people in 2 months + 1 person in 4 months

slide-3
SLIDE 3

Lies, Darned Lies & Metrics

¨ Person-year common measure of work performed

¤ Work done by 1 person over 1 year ¤ 12 people in 1 month also a person-year of work ¤ Or 4 people in 2 months + 1 person in 4 months

¨ Among stupidest metrics ever & ever

¤ Often see coders’ productivity vary by 10x ¤ Ignores meetings, sick days, hangovers in calculation ¤ Can do a lot more in an 8-hour day vs. 8 1-hour days

slide-4
SLIDE 4

Do Person-Months Scale?

slide-5
SLIDE 5

Teamwork Problems

¨ Team must stay organized to avoid wasting effort

¤ Better tasks understood, easier to work in parallel ¤ Time lost to bugs & duplication when confused or lost

¨ Need to hit deadlines, so important to track progress

¤ Early alerts critical to add developers before crunch ¤ Asking developers to track progress adds to overheads

¨ Accountability important to make team a team

¤ Requires detailed tracking so all know who did each step ¤ Ensure responsibility if when others do not pull fair share

slide-6
SLIDE 6

Teamwork Problems

¨ Must provide direction for team to finish work ¨ On-time completion ensured by tracking progress ¨ Prevent slacking & reward excellence also important

Too much communication wastes time Too little communication wastes efforts

slide-7
SLIDE 7

Brooks's Law

¨ Repeating pattern observed by Fred Brooks ¨ Rejects person-months for a different reason

Brooks’s Law

Adding programmers to a team when a product is late makes the product even later.

slide-8
SLIDE 8

¨ Course created to provide real-world experiences ¨ Must reflect reality for learning/lessons to matter

¤ Demand groups maintain project & its history in Git ¤ Scrum board records status of project and work done ¤ Tasks & tests breakup work for parallel development

Reality Is Important…

slide-9
SLIDE 9

¨ Team rarely keeps project from start to end

¤ Larger companies have specialized sales (or QA) teams ¤ Developers leave & replaced so project keeps going ¤ Events create changes due to promotions or reorgs ¤ Capturing knowledge critical for project to succeed

Reality Is Important…

slide-10
SLIDE 10

You Are Your Own User

slide-11
SLIDE 11

You Are Your Own User

slide-12
SLIDE 12

¨ Every artifact is always written once & only once

¤ Writer's viewpoint useless – they already know meaning ¤ Documents made to last – need to think long-term use

¨ Documents read many times over project lifespan

¤ Most common reason: trying to solve current problem ¤ Searching like Google results – does page 2 even exist?

Why Artifacts Written

slide-13
SLIDE 13

¨ Time spent reading could be time solving problem

¤ Tradeoff can be good if total time needed is reduced

¨ Always work to get readers to payout faster

¤ Benefits & initial steps clear to get them on their way ¤ Be explicit with needed details: do not make them ask

Writing Artifacts Well

slide-14
SLIDE 14

Document Creation Key Concept

Write once

Read often

Optimize effort: Write documents to be read

slide-15
SLIDE 15

Getting Up To Speed

¨ Even here only have few minutes for first impression

¤ Make first steps enticing to encourage correct actions ¤ Create rewards to make users "successful" from the start

¨ What is most common trick used right now?

¤ Play to their vanity: making showing-off easy ¤ Common icon sets get users acting without thinking

slide-16
SLIDE 16

¨ Easiest to follow when names & usage are parallel

String.compareTo(String str) String.compareToIgnoreCase(String str)

Writing Code to be Used

slide-17
SLIDE 17

¨ Easiest to follow when names & usage are parallel

String.compareTo(String str) String.compareToIgnoreCase(String str) String.equals(String str) String.equalsIgnoreCase(String str)

Writing Code to be Used

slide-18
SLIDE 18

¨ Easiest to follow when names & usage are parallel

String.compareTo(String str) String.compareToIgnoreCase(String str) String.equals(String str) String.equalsIgnoreCase(String str) String.regionMatches(boolean iC,String str) String.regionMatchesIgnoreCase(String str)

Writing Code to be Used

slide-19
SLIDE 19

¨ Easiest to follow when names & usage are parallel

String.compareTo(String str) String.compareToIgnoreCase(String str) String.equals(String str) String.equalsIgnoreCase(String str) String.regionMatches(boolean iC,String str) String.regionMatchesIgnoreCase(String str)

Writing Code to be Used

slide-20
SLIDE 20

¨ Easiest to follow when names & usage are parallel

String.compareTo(String str) String.compareToIgnoreCase(String str) String.equals(String str) String.equalsIgnoreCase(String str) String.regionMatches(boolean ignoreCase, …) String.regionMatchesIgnoreCase(String str)

Writing Code to be Used

slide-21
SLIDE 21

¨ Easiest to follow when names & usage are parallel

String.compareTo(String str) String.compareToIgnoreCase(String str) String.equals(String str) String.equalsIgnoreCase(String str) String.regionMatches(boolean ignoreCase, …) String.regionMatchesIgnoreCase(String str)

Writing Code to be Used Tick Users Off

slide-22
SLIDE 22

Parallel names reduces learning times and increases users comfort

Writing Code to be Used

slide-23
SLIDE 23

¨ Use metaphors, but stay consistent to ideas created

Employee.changeName(String newName) Employee.fileAnnualReport()

Appeal to Intuition

slide-24
SLIDE 24

¨ Use metaphors, but stay consistent to ideas created

Employee.changeName(String newName) Employee.fileAnnualReport() Employee.setupFirstUse() Employee.disconnect()

Appeal to Intuition

slide-25
SLIDE 25

¨ Use metaphors, but stay consistent to ideas created

Employee.changeName(String newName) Employee.fileAnnualReport() Employee.setupFirstUse() Employee.disconnect() Employee.setColor(String clr) Employee.clone()

Appeal to Intuition

slide-26
SLIDE 26

Metaphors are great When they make sense

Writing Code to be Used

slide-27
SLIDE 27

Inheritance To Confuse

¨ Typically we teach inheritance as IS-A relationship

¤ Square IS-A Rectangle, so Square extends Rectangle ¤ House extends Building, since House IS-A Building

¨ IS-A relationship sometimes correct for inheritance

¤ House needs Building properties & then adds to it ¤ Any place generic Building used, House also appropriate

¨ But IS-A not always correct & create more problems

¤ Square's length & width cannot differ like Rectangle ¤ Replacing rectangle with square will not usually work

slide-28
SLIDE 28

Liskov Substitution Principle

¨ Initially stated by Barbara Liskov in 1987

¤ Clearest approach to know when inheritance appropriate

Subtypes … usable anywhere supertype used

slide-29
SLIDE 29

Inheritance To Be Used

¨ For House & Building, IS-A & LSP both work

¤ Using House as Building works in all situations ¤ Logical to keep all Building properties in House ¤ House is subclass & Building is superclass

Building b = new House(); Floor ground = b.addFloor(); b.addExit("Front Door"); requestZoningChange(b, "Daycare"); simulateTrafficImpact(b, 20); float f = solarPotential(b);

slide-30
SLIDE 30

Inheritance To Be Used

¨ For Square & Rectangle IS-A, but not LSP, work

¤ Using Square as Rectangle odd & not a good fit ¤ Keeping Rectangle's properties in Square yucky

Rectangle r = new Square(); sizeAsTopOfBox(r); r.setDimension(23, 67); r.width = 2; r.length = 45; // What happens to width? int arr = r.calcArea();

slide-31
SLIDE 31

Inheritance To Be Used

¨ For Square & Rectangle IS-A, but not LSP, work

¤ Using Square as Rectangle odd & not a good fit ¤ Keeping Rectangle's properties in Square yucky

¨ Rectangle extending Square 's good , however

Square s = new Rectangle(); sizeAsTopOfCube(s); s.setDimension(23); s.width = 2; s.length = 45; int arr = s.calcArea();

slide-32
SLIDE 32

Don’t Repeat Yourself

¨ Redundancy creates confusion & invites problems

¤ Why are multiple needed? ¤ What is importance of each one? ¤ Do they have to remain identical? ¤ What happens if they do differ?

¨ Tiny changes even worse; invites theorizing reasons

slide-33
SLIDE 33

¨ Eliminate redundancy in:

¤ Requirements ¤ Design ¤ Modules ¤ Subroutines ¤ Data ¤ Comments ¤ Documentation ¤ Anything else

DRY Always Applies

slide-34
SLIDE 34

¨ Eliminate redundancy in:

¤ Requirements ¤ Design ¤ Modules ¤ Subroutines

¤ Data

¤ Comments ¤ Documentation ¤ Anything else

DRY Always Applies

slide-35
SLIDE 35

¨ Abstracting common code into single location…

¤ …but good idea when code MUST ALWAYS BE identical

¨ Are requirements same or is it just coincidence?

¤ Cannot predict any future demands and changes ¤ Changes could break this connection unless required ¤ Really sucks when code breaks for no apparent reason

DRY In Code

slide-36
SLIDE 36

Checking Rules Followed

slide-37
SLIDE 37

Checking Rules Followed

slide-38
SLIDE 38

¨ Some of biggest potential savings available

¤ Code reviews can save 100x their cost in related work ¤ Team used to review problem code or important merges

Collaborations ==

Enforcing these Standards

slide-39
SLIDE 39

Style is Not The Goal

slide-40
SLIDE 40

How Style Issues Handled

slide-41
SLIDE 41

¨ Invite reviewers, schedule review, & share code

¤ 200-400 lines of code is maximum for single review

¨ Make clear to invitees explicit goals for review

¤ Ugly, but critical, code that must be easily updated ¤ Could be that author needs help finding recurring bug ¤ New hire needs to learn standards & culture of group

¨ Invitees do their homework; must arrive prepared

¤ Bring notes of potential issues and be ready to discuss

How We Review Code

slide-42
SLIDE 42

¨ Time is money: last at most 2 hours (& ideally less)

¤ More than enough time to make progress ¤ Limits boredom (or worse) from setting in ¤ Creates constant need to skip past meaningless details

Code Review Meetings

A committee is a group that keeps minutes, but loses hours.

Milton Berle

slide-43
SLIDE 43

¨ Moderator

“Traffic cop” running meeting & keeping things moving Invited members, shared agenda, & distributed code Keeps focus on finding issues; fixes not for committee Sees to end by overseeing final report & resulting actions

Roles At the Review

slide-44
SLIDE 44

¨ Moderator/moderatrix

¨ Scribe

Records errors, issues, & potential refactorings found Notes for attendee the tasks assigned at meeting’s end

Roles At the Review

slide-45
SLIDE 45

¨ Moderator/moderatrix ¨ Scribe

¨ Reviewers

Stays on topic & only talk about possible problems Writeup results assigned to document what must happen

Roles At the Review

slide-46
SLIDE 46

¨ Moderator/moderatrix ¨ Scribe ¨ Reviewer

¨ Author

Quietly sits in corner & soaks up the wisdom Speaks only to answer questions asked directly Thanks attendees profusely for their time & help

Roles At the Review

slide-47
SLIDE 47

¨ Moderator/moderatrix ¨ Scribe ¨ Reviewer ¨ Author

¨ Manager

Buys lunch

Roles At the Review

slide-48
SLIDE 48

How Do Others Solve It?

¨ Agile stole practices common in areas outside CSE

Dancing Luge Figure Skating Showering

slide-49
SLIDE 49

¨ Improve process by always working with partner

Agile's Solution

slide-50
SLIDE 50

Agile's Solution

slide-51
SLIDE 51

¨ Collaborative development works

¤ Pair-programming 20x more efficient than testing ¤ Saw 25x drop in errors by reviewing 1-line fixes

Sadly True

slide-52
SLIDE 52

¨ Goal is team performance & focus remains on team

¤ Individuals may come & go, but team will continue

Agile Key Point

slide-53
SLIDE 53

¨ Goal is team performance & focus remains on team

¤ Individuals may come & go, but team will continue

Agile Key Point

slide-54
SLIDE 54

¨ Goal is team performance & focus remains on team

¤ Individuals may come & go, but team will continue

Agile Key Point

slide-55
SLIDE 55

Project teams will not change

Last Detail for Today…

slide-56
SLIDE 56

For Next Lecture

¨ Get first sprint submission ready within your team

¤ Focus on important details & review grading rubric ¤ Software engineering class, not just "make it cool"