EclipseCon 2009/BoF/Agile

• agile applied to agile: you need to be agile with agile
• try out small changes to your process
• put in measures to detect failures early

crutique about things that slow you down

• lack of out-of-the-box CI support
• legacy code that gets in the way of doing design using doing TDD and mock-objects
• checking in broken code

on being 'agile with agile':

• if agile does not work for you then you need to change it
• there's no process, but there's still order in the percieved chaos
• the process is not the king, people are

• many forms of Agile, even RUP can be agile if done right
• working through the problems, not around it (1 day code freeze to stabilize things is not a solution, repetitive builds with tests that run every check in is)

• less fat in the UI -- better APIs in the core, that can be tested

Anti-Patterns:

• Commenting out Tests to get the Build Green.
• Fudging the I-Builds so that it looks like the build passed, when it is broken.
• Varying Iteration Lengths.
• Delaying Refactoring
• Integrating code only at the end of the day.
• Less than 80% code coverage in unit tests.
• Code checked in that isn't covered by a test.
  • Continuous Integration Anti-Patterns (http://notdennisbyrne.blogspot.com/2007/09/top-5-signs-of-discontinuous.html):
    • Not checking code in for days.
    • Red builds getting promoted to production
    • Code Freezes for stabilization.
    • Hating to do Merges because of the number of changes.
    • Integration Test suite uses stubs, and doesn't test the actual code.
    • Not building from head.
    • Not building after each check in.

agile and TDD: - TDD is not about coverage alone. It is about letting the tests help you focus on solving the problem. A failing test should point out that something is broken. Generating tests for getters is not going to help you in any way, it is just going to slow you down. - low coverage is a symptom of using a flawed method of producing working software. Fix the method, not write tests afterward

Agile Estimating and Planning

• What makes a plan Agile?
  • Updated every iteration.
  • Backlog reviewed every iteration.
  • Detail plan only one iteration out.
• Planning for Eclipse Projects
  • Bugzilla as a Backlog
  • Every feature, bug, or work item must have a bugzilla entry.
  • Only assign work that is to be worked on.
• Iteration Reviews

Slightly off topic stuff

on tests for getters-and-setters:

• TellDontAsk It is okay to use accessors to get the state of an object, as long as you don't use the result to make decisions outside the object. Any decisions based entirely upon the state of one object should be made 'inside' the object itself.
• LawOfDemeter "Only talk to your immediate friends." - A.getA().getB().getC().getD() is considered bad design, you're talking to friends-of-friends-of-friends to get anything done