Ivan Gevirtz

Keep it Simple

Keep it Important

Keep it Working

Share knowledge

Iterative Development == Responsiveness to Customer

Done now --> Perfect Later

Make mistakes early

Defer and you'll know the problem better

General Agile Principles

Always do the most important thing next.  Everything else may be important, but not the MOST important.  There is no second place.  Multi-tasking wastes time, and task-swapping/context switching/continuous partial attention is costly in wasted time.

• Thin vertical slice / Bite sized chunks
• Most important first
• User stories
• Reprioritize
• Short Iterations
• Frequent releases
• Collective ownership
• Make mistakes early, learn, and don't repeat!
• Under promise and over deliver
• Track Estimates

Results

• Solution for today, migration path to future
• Responsiveness to market
• Quality software

XP Processes

• Standup Meetings -- A standup is a daily status update.  Each engineer has ~45 seconds to raise issues and update others
• Iterative development == Responsiveness to customer
• Test First == Ship to customer shortly after code complete
• Release Cycle == Quick reprioritization
• Metrics (progress, timing, changes, etc...)

Development

Mechanics

• Engineers should make estimates
• Frequent check-ins & commits
• Test first -- At least know what acceptance criteria need to be met and how to prove they have been met
• Constant refactoring
• Pair programming is better than code review in many cases
• Integrated code review
• Integrated QA

Laws

• Document (via automated tests!) and meet all acceptance criteria
• Priority order
• Actually completing code -- Including relevant documentation
• No Commit and Run   -- Code must build, and ALL Unit tests must pass.  Do not regress other people's code/bugs.
• Commit early, commit often (bite sized chunks)  -- If you commit early, then it makes it someone else's problem not to break your stuff
• Interface frozen --Talk to people about your changes
• It's okay to commit a bug -- Just stub out calls and check in small pieces of code (move your own code forward)
• Attend standup meetings.

Asserts

• Respect code freezes: Lock down source tree to give sufficient time to setup/build source tree
• Code commenting: Use appropriate scope.  Include
• • Interfaces
  • Tests
  • Non-local changes
  • Describe why you did the code, not how
  • Do not duplicate info
  • No need to c omment every function block
• Pair programming: Design in pairs and develop a test catalog first.  Have one developer write the interface and the other code the unit tests.
• Design Reviews: Varying scope requires varying degrees of review. For each component, design review looks at interfaces, commented header files, commented set of human-readable tests.
• Documentation: Use as appropriate for each story. Before you start coding look at public interfaces and test criteria.

Design

• Design in pairs or as a team.
• Development is driven by the creation of unit and functional tests that accommodate rapid changes with confidence
• Develop a test catalog first; then one write the interface and one write the unit tests
• Design Reviews
• varying scope requires varying degrees of review (during tasking, during large-block design)
• For each component, design review looks at
• • Interfaces
  • commented header files
  • commented set of tests (human readable).  Each test needs assertions
  • Documentation - as appropriate for each story
  • Before you start coding, look at public interfaces and test criteria

Design & Code Reviews:

• Design review will be done by team leads or other suitable devleoper.
• Code must have a code review.  Often by a team member, but sometimes it is better to use someone uninvolved.
• No code checked in without code review.  Pair or code reviewer should be explicitly mentioned in the checkin comment, and the reviewer is on the hook to answer problems going forward, so the reviewer should understand the code and be thorough and diligent.
• To do a code review, start with, "Tell me what this code does."

Refactor

• Avoid code rot -- Refactor constantly
• But don't think refactoring is an end, refactor only when enhancing code.  Refactoring isn't a goal in itself.
• Remove dead, orphaned, or unused code.  If it's ever needed later, you'll know the problem and be able to do a better job then.
• Testing first before refactoring ensures the refactor doesn't break things
• Book recommended Refactoring Martin Fowler.  Ivan has it to lend :-)

• Also, refactoring goes beyond code.  Refactor the process, the organization, etc...

Test First

• Don't let your unit tests turn into integration tests
• Do we need to go back and add unit tests?  Only when refactoring code.  And only refactor when adding functionality.
• Need automated tests, both unit and functional
• Publish the contract/ the interface
• Test first will help with freezing APIs