Course Goals

To provide Sr. Developers and Tech Leads with understanding of concepts and approaches for providing Feedback to improve Code Quality and support the goal of improved Flow.

• Define the Goals of DevOps and Flow
• Use Code Review and Design Review as Feedback, KT, and Training
• Recognize how Design Feedback supports Code Quality
• Define the multiple perspectives to apply during Code Review
• Expain how tools inc. GitHub and Eclipse support Code Review
• Define the concepts of Good Code, Clean Code, and Livable Code
• Explain how to apply standard Code Quality tools like SonarQube and CheckMarx
• Apply Coding Guidelines to Automated Tests
• Apply Team Guidelines to improve Flow and reduce cycle time

Agile Manifesto

Agile Manifesto Principles

Activity 1: About Code Reviews

Brainstorming: Identify one each of

• Value of Code Reviews
• Problem faced in Code Reviews
• Knowledge/Skill needed for Code Reviews

Resources

• 12 Days of Agile Principles (youtube, broken link)
• Agile Manifesto

Section 1: The Problem to be solved

Why Code Reviews

| Quality | Training | Behavior and Culture | |———|———-|———————-| | But to what goal? | For Whom? | Bot to what behaviors? | | Environment Stability | Training | Entineering Discipline | | | + Technology | Craftsmanship | | Reduce Defects | + Best Practices | | | | + Team Norms | T.E.A.M | | Reduce Testing Costs | + Knowledge Transfer | Collaboration and Communication | | (save time/money now) | | | | Improve “-ilities” | Code Reviewer | Team Accountability | | aka. non-functional requirements | + Technology | | | (save time/money later) | + Best Practices | | | | + Knowledge Transfer | |

Additional Reading

Why code reviews matter (and actually save time!)

10 Things developers wished their bosses understood about code review

Unlearing toxic behaviors in a code review culture

Section 2: DevOps 3 Ways

Learing Objectives:

1. Define the 3 Ways of DevOps
2. Describe the Principles of Flow
3. Describe the Principles of Feedback
4. Describe the Principles of Continual Learning and Experimentation

Introduction to 3 Ways of DevOps Thinking

3 Ways of DevOps Thinking, by Gene Kim

The First Way: The Principles of Flow

1. Make the work visible
   • From Idea to Delivered
2. Limit Work in Progress (Agile Principle #7)
   • ie. Multitasking Bad
   • David J. Andersen - “Stop starting. Start finishing.”
3. Reduce Batch Sizes
   • Critical for shrinking lead times and increasing quality
   • Single-piece flow
4. Reduce Number of Handoffs
   • Handoffs create queues and require communication
5. Continually Identify and Elevate our Constraints (Agile Principle #12)
   • There is always ONE Constraint
6. Eliminate Hardships and Waste in the Value Stream (Agile Principle #12)

source: The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, & John Willis

• In an Agile organization we make work visible with Kanban boars
• In an Agile organization we provide value not by starting work, but by finishing work
• In an Agile organization small stories provide Focus, Flexibility, quicker Feedback, and reduce Risk
• In an Agile organization we focus on Collaboration and Cross-Functional teams to reduce handoffs
• In an Agile organization we Inspect and Adapt at regular intervals
• In an Agile organization we eliminate Waste to increase the Value delivered

In Scaled Agile we call this Technical Agility

Reduce Batch Sizes

One Piece Flow

• One-piece flow
• Defensive Scope

Eliminating Waste

The 8 Wastes (The Hartford Way)

1. Defects
2. Over Production
3. Waiting
4. Non-utilized Talent
5. Transportation
6. Inventory
7. Option
8. Extra Processing

Eliminating Waste - The DevOps Wastes

From Implementing Lean Software Development

• Partially Done Work
• Extra Processes
• Extra Features
• Task Switching
• Waiting
• Motion
• Defects
• Nonstandard or Manual Work
• Heroics

What do we call Partially Done Work?? - NOT DONE

Extra Features == Over Production!

https://agility.im/frequent-agile-question/how-do-the-lean-7-wastes-apply-to-software-projects/#:~:text=Since%20lean%20is%20the%20grandfather,also%20improving%20time%20to%20market.

The Second Way: The Principles of Feedback

To Work Safely in a Complex System

1. See Problems as They Occur
   • Feedback Loops
2. Swarm and Solve Problems to Build New Knowledge
   • Contain, Diagnose, and Treat
3. Keep Pushing Quality Closer to the Source
   • Find and Fix in your area of control
4. Optimize for Downstream Work Centers
   • Most important customer is next step downstream

• Feedback loops must be Fast, Frequent, and High Quality information
• Feedback loops are required in our process and in our applications
• Contain the problem to prevent it from spreading
• Diagnose and Treat the problem so it cannot recur
• Swarming prevents the problem from progressing downstream, prevents start of new work which may have the same problem, and enables learning
• Safety responsibility and decision making must be local to the work
• Quality is everyone’s responsibility
• Optimize for Downstream by designing for QA, Release, and Operations/Support

The Third Way: Principles of Continual Learning and Experimentation

1. Enabling Organization Learning and a Safety Culture
   • Blameless Post-mortem
2. Institutionalize the Improvement of Daily Work
   • Explicitly reserve time to improve system
3. Transform Local Discoveries into Global Improvements
   • Libraries of post-mortem reports, shared code, libraries, and configurations
4. Inject Resilience Patterns into Our Daily Work
   • Reduce Risk by improving operations
5. Leaders Reinforce a Learning Culture
   • Promote Inspect and Adapt

source: The DevOps Handbook by Gene Kim, Jez Humble, Patrick Debois, & John Willis

• Look for how to redesign the system to prevent accident/failure rather than focusing on human error
• Without improvement in Daily Work processes don’t stay same, they degrade
• Convert individual expertise into artifacts usable across enterprise
• Constantly experiment in daily work to identify improvements

Closing the Loop

Where do Code Reviews fit in?

• Flow
  • Must make review work Visible, include tasks w/ realistic estimates
  • Reduce change sizes to enable faster reviews
  • Opportunity to identify constraints in Design & Code, slowing development
  • Opportunity to identify and eliminate waste from partial work, extra changes, and defects
• Feedback
  • This is where the BENEFITS are
  • Feedback on Code Reviews? Absolutely
• Learning and Experimentation
  • Code Reviews aren’t personal
  • Turning review feedback into global knowledge
  • As Leaders promote learning, praise good work, promote trying new/different things

Section 3: The Code Review

Learning Objectives:

1. The Process
2. The Tools
3. The Perspectives

Process: GitHub Flow

GitHub Flow

• Create a branch
• Add Commits
• Open a pull request
• Discuss and review code THIS RIGHT HERE
• Deploy
• Merge

Make the work Safe for the entire system

Feedback in-context

Principles:

• 1.1 make work visible
• 1.3 Reduce batch sizes
• 2.1 See problems as they occur
• 2.3 Push quality closer to source
• 3.1 Learning Organization and Safety culture
• 3.2 Improvement of Daily Work

Process: Pair Programming

Pair Programming

• Lower defects, deliver faster, higher quality
• Reviewing together
• Not just for TL and Dev, can also be peer-to-peer
• Early feedback - See Problems as they Occur, and Push Quality Closer to the Source

The Coder

Small Picture - the actual change, the “diff”

• Good Code, Clean Code
• Expected and unexpectec changes
• Accidental changes/commits

person at keyboard/desk

The Designer

Big Picture - changes in context of the whole system

• Align to Design discussion
  • Discuss design before coding
• Team Design Standards and Patterns

construction supervisor

The Architect

Future Picture - changes in context of future growth/needs

• Provide architectural runway
• Align with architectural roadmap

quote: Does ‘high-rise’ refer to the building or the budget?

Resources

Pair Programming

Section 4: Good Code, Clean Code, and Livable Code

Learning Objectives:

1. Define Clean Code
2. Define Good Code
3. Define Livable Code

Robert Martin on Clean Code

Code Quality Measurement: WTFs/Minute (commadot.com)

youtube link broken, was it Rob Martin on Clean Code?

Reading: Clean Code: A Handbook of Agile Software Craftsmanship

Clean Code

Basic Guidelines

• Meaningful Names
• Do One Thing
• DRY
• Good Comments vs. Bad Comments
• Formatting
• Error Handling
• Refactor to Improve Readability
• Unit Tests & TDD
• Single Responsibility Principle
• Code Smells and Heuristics

Read the book, there is much more

source: Clean Code by Robert C. Martin

Activity 4: Good Code

What is Good Code?

• Identify at least 5 attributes of good code.

different people, different perspectives, some overlap, many different thoughts

Good Code

Good Code is…

• Functional
• Clean … ?
• Non-Functional Requirements…

Livable Code

Basic rules of Livable Code

• Don’t make it worse
• Improvement over Consistency
• Inline Everything (no big bang)
• Liaise (don’t ask permission, don’t ask forgiveness)

• You have to Live Here (you get to live here)

• The important part of software is no the code
• The important part of software is not the people
• The important part of software is the system

Sarah Mei on Livable Code

Resources

Clean Code Principles

Section 5: Code Review and Automated Tests

Learning Objectives:

1. Define the Three Laws of TDD and FIRST
2. Main Attributes of Test Automation

Three Laws of TDD and FIRST

Three Laws

• Test First
• Write Enough Test to Fail
• Write Enough Code to Pass

F.I.R.S.T.

• Fast - tests must run quickly
• Independent - tests must not depend on each other
• Repeatable - tests must be able to run anywhere
• Self-Validating - tests must be boolean - they either pass or fail
• Timely - tests should be written just before coding

source: Clean Code by Robert C. Martin

Maint Attibutes of Test Automation

• Maintainability
• Reliability
• Flexibility
• Efficiency
• Portability

Sound familiar? … Good Code!

Resources

OWASP Code Review Guide

Section 8: Team Guidelines

Learning Objectives:

1. Identify the Value of Team Guidelines
2. List the DevOps Principles supported by Team Guidelines
3. Examine Options for Effective Guidelines

Activity 5: Team Guidelines

Identify at least one of each:

• A Benefit of Team Guidelines (Three Ways)
• A Topic to include in Team Guidelines
• A Suggestion for Effective Guidelines

(it isn’t just for Styles)

Why Team Guidelines

The First Way: Flow

1.6 Eliminate Waste

• Partially Done
• Task Switching
• Waiting
• Motion
• Defects

The Second Way: Feedback

2.2 Build Knowledge

• Problems become new Guidelines

2.3 Quality at Source

• Knowledge in hands of Developers

2.4 Optimize for Downstream

• Code Reviewer is Downstream

The Third Way: Learning and Experimentation

3.1 Learning Culture

3.3 Local Discoveries

3.5 Leaders Reinforce Learning

Resources

The Team Coder - How to Establish Coding Guidelines in Your Team

For Leaders

What to Expect

• No Silver Bullet for Quality
  • Code Reviews will not solve all of your quality problems, keep looking Left
• Not an Instant Transformation
  • Improvements will take time
• Development Work Will Slow Down
  • be prepared to adjust your plans
    • If team is not doing code reviews today (or not doing well), then this introduces new tasks which take time
    • If tema has poor quality today, then they will spend more time in rework
• Friction
  • Some developers may see reviews as criticism
  • Some reviewers may present feedback as criticism
• Identify Poor Performers and prepare to manage them OUT
• Expect from Developers
  • Resistance - “reviews are slowing us down”
  • Chreish those who Embrace this movement
• Expect from Code Reviewers
  • Need ongoing mentoring on reviewing/collaboration skills
  • It may be a bumpy start

What to Avoid

• “Toxic” behaviors that break down teams, instead
  • Encourage Collaboration and Respect
• Set schedules and Code Review “Meetings” (risks slowing Flow), instead
  • Encourage Collaboration while coding - pair/mob programming
  • “Offline” code reviews, leveraging available tools (GitHub)
  • KT and sharing sessions after or as part of Done
• Documented “checklists” on every story, instead
  • Include Code Reviews as part of Definition of Done
• Exhaustive Code Review checklists, instead
  • Prefer to document and share Team Guidelines

How You Can Help

Encourage Code Reviews as collaboration, praise good work, and helpful behaviors

Encourage creation/evolution of Team Guidelines

Encourage review/revisit of Definition of Done

Encourage/Help team set aside time for Code Reviews

Encourage team to focus on small sized work - recommended by both Agile and DevOps practices - helps to make Code Reviews more efficient

10 Things developers wished their bosses understood about code review

Additional Reading

Why code reviews matter (and actually save time!)

10 Things developers wished their bosses understood about code review

Unlearing toxic behaviors in a code review culture