James McCaffrey

I was blessed at this conference to meet with my old college professor. You know that one teacher that influences and inspires you? That's who Dr. McCaffrey is to me. It started 1996.

I was in the Army at the time stationed at Schofield Barracks Hawaii. Most everyone who is enlisted in the Military Police corps says that they are going to get a degree in criminal justice. I was no different, but that is not the direction I went. My second class was Computer Science 101 at Hawaii Pacific University. Classes were held on the many military bases on the main island of Hawaii.

I remember the first day of class – I was hooked after that first program that said "What is your name?" followed by a personal greeting. Dr. McCaffrey made programming exciting. I recall learning about subroutines and variables and types. He inspired greatness. Every class was filled with engaging stories and lots of poking and Lawyers and Accountants. Every class was well-organized. Homework was graded mostly on "neatness and completeness."

He was so popular among students that people would arrive early on registration days to get a seat in his classes. I remember dragging Janel and our infant children at 2 A.M. to the Schofield Barracks library to be sure I was the first in line to get in his class :-)

I was the first in his class again yesterday. He taught an intro to Earned Value Management – yuck… he even made that subject interesting with his teaching style. I had a good visit with him and got these pictures:

Agile Test Automation Development

Instructor: Monica Luke
Test Automation Architect at IBM Rational
Been doing this for 17 years

Automate early, automate often

Going Agile

Plan for an extended transition – it is a culture shift
Transition is hard for development
Need to build a sense of urgency

Aside: most companies seem to apply only parts of Agile

Benefits:
* Incremental deliveries
* Visibility: deliver often, demo often
* Team morale: better productivity, less burnout

Challenges:
* Quick moving cycles
* Planing is key, as is estimation
* Just enough process to be visible and predictable

Test and Test Automation is the bomb

Aside: most organizations represented here seem to have dedicated groups – for analysis, development, and testing. Few seem to have people that do "everything."

What to automate and when. Avoid automate moving targets. Ask: what are your manual test pain points?

What is the right insertion point:
* API
* GUI
* Product Architecture

Going Agile: A Case Study

1. Select Practices to Adopt
2. Implement, Evaluate, Adapt
3. Adopt or Reject Practices
4. Goto 1

Time boxed iterations
- Three weeks
-- 1.5 days planning
-- 12 days coding
-- 1.5 days testing

Shorter iterations (2 or 3 weeks) build a sense of urgency.

The Joy of Legacy Code

6/9/2010
Michael Feathers

Legacy systems are not "sexy" but they are still doing useful/interesting work

Code is biological
A kudzu vine that grows and grows, takes over an ecosystem over time
The aesthetic is different in a large system: our standards may need to change

We align with the things that are easier over time
adding code to an existing function is easier
therefore functions will get longer
classes will get bigger
extra work to create a new class/function: think of a new name, more keystrokes, etc

Morale: how are we going to make progress on this code that isn't always pretty
attainable goals: hard to feel like you're making progress
Code coverage as a metric: you could spend your entire career trying to get to 100%
Adding automated tests to code that is already working can be futile
Add tests to code you are about to change, as a feedback mechanism
Some areas are changed much more frequently than others
Hotspots will gain test coverage sooner than you think, you may be pleasantly surprised

Useful metrics:
Change coverage: find the areas where you have the most commits
Count all commits in a file towards this metric once that file has tests

The hardest part of adding tests to legacy code is breaking the dependencies to attain isolation for unit tests

Method Object
Martin Fowler's Refactoring Catalog
Take a method and turn it into a new class with all the code in a run() method
Allows you to move forward in interesting ways

There is a one time cost for testability
Hardest part of creating tests is breaking dependencies
Once you have broken the dependencies adding more tests will be much easier

Isolate Sections
Higher levels of testing are also valuable
Easy to have changes propagate far away from the actual change
It's easy with singletons to modify states from any place: so people do modify it from any place
Componentize large sections are consolidate the globals: totally eliminating them might be too difficult in a large existing system

Exploit Natural Encapsulation
The main problem with legacy code is understandability: use Understand tool to examine the structure of your code and create new classes that are already naturally encapsulated

Name the Thorny Areas
"Quince's Quagmire"
Wall Map with your visualization of the system "here be dragons"
Dismisses the fear associated with particularly nasty code
Some gallows humor...

Wounded Giant Metaphor
Approach it like a doctor: the existing code is not an enemy, you're trying to make it better

Heroic Stories
Sharing war stories. Develop a folklore about the code you're working on

Other metaphors: Code as a garden, code as a playground

Explain your system as simply as possible, ideally 4 elements or less, as a way to start owning/exploring the code. A way to get a foothold of understanding

Scratch Refactoring
You have a big piece of code and no idea where to start refactoring
Refactor it to hell, dont test it, dont even compile it, and then throw it away
Not a waste of time because you will understand more about what's there

Viking Laws
-be brave & aggressive
-be direct
-be versatile and agile
-attack one thing at a time
-be prepared
etc....
attitude is everything
You *can* apply creativity to a legacy code

Books

Working Effectively With Legacy Code by Michael C. Feathers

Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science) by Julie Sussman, et al.

Test Driven Development: By Example by Kent Beck

Performance & Security Testing in Agile Development

6/9/2010
Tracy DeDore (HP)

Testing baked into each sprint: cant be a manual approach
Not uncommon to take a hybrid approach between agile/waterfall: scrummerfall
Important to be diligent when mixing practices
Non-functional testing often gets deferred till the end: risky
Functional/performance/security testing should be addressed in release planning & each sprint

automated load testing: bottlenecks/root cause analysis etc for performance degradation
wont have a working full application every sprint: need to be able to test components
headless/gui-less performance testing
Service virtualization tools: capture/model target system's behavior/performance so you dont need to use live systems for testing each time

static source code analysis: scan for vulnerabilities during dev: many false positives
step or path-specific business process testing
black box/dynamic web application scanners: requires a fully functioning app
leverage automation tools: allows dev & QA to test without being security experts

Manifesto for Agile Software Development

First principles of Agile, from http://agilemanifesto.org/

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Tim Lister keynote