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

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 in 2 months + 1 person in 4 months

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

Do Person-Months Scale?

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

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

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 .

Reality Is Important… ¨ 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… ¨ 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

You Are Your Own User

You Are Your Own User

Why Artifacts Written ¨ 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?

Writing Artifacts Well ¨ 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

Document Creation Key Concept Write once Read often Optimize effort: Write documents to be read

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

Writing Code to be Used ¨ Easiest to follow when names & usage are parallel String.compareTo(String str) String.compareToIgnoreCase(String str)

Writing Code to be Used ¨ 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 ¨ 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 ¨ 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 ¨ 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 ¨ 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 Parallel names reduces learning times and increases users comfort

Appeal to Intuition ¨ Use metaphors, but stay consistent to ideas created Employee.changeName(String newName) Employee.fileAnnualReport()

Appeal to Intuition ¨ Use metaphors, but stay consistent to ideas created Employee.changeName(String newName) Employee.fileAnnualReport() Employee.setupFirstUse() Employee.disconnect()

Appeal to Intuition ¨ Use metaphors, but stay consistent to ideas created Employee.changeName(String newName) Employee.fileAnnualReport() Employee.setupFirstUse() Employee.disconnect() Employee.setColor(String clr) Employee.clone()

Writing Code to be Used Metaphors are great When they make sense

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

Liskov Substitution Principle ¨ Initially stated by Barbara Liskov in 1987 ¤ Clearest approach to know when inheritance appropriate Subtypes … usable anywhere supertype used

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);

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();

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();

D on’t R epeat Y ourself ¨ 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

DRY Always Applies ¨ Eliminate redundancy in: ¤ Requirements ¤ Design ¤ Modules ¤ Subroutines ¤ Data ¤ Comments ¤ Documentation ¤ Anything else

DRY Always Applies ¨ Eliminate redundancy in: ¤ Requirements ¤ Design ¤ Modules ¤ Subroutines ¤ Data ¤ Comments ¤ Documentation ¤ Anything else

DRY In Code ¨ 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

Checking Rules Followed

Checking Rules Followed

Enforcing these Standards ¨ 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 ==

Style is Not The Goal

How Style Issues Handled

How We Review Code ¨ 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