Agile '05 conference, part 2
More from the Agile 05 conference...
Delivering APIs in an Agile Context, John Major
John Major described a project that was doing custom programming of lab workflows as part of the Human Genome Project. This was an environment with lots of churn: biology, instruments, J2EE.
- Stable APIs vs. agile change
- General features vs. "Do the simplest thing that could possibly work"
- Frameworks vs. global refactoring
- Framework design vs. features
The result was a platform API, a mix of data-driven (configuration) specification and custom code. The team had the attitude toward process, "We'll try anything for a month." There was lots of testing. They used Jemmy with Swing.
- Internal support: old and new features. Used the idea of "office hours" for support. Provided training. Tried having platform developers work on applications, but it didn't work so well.
- Lightweight code reviews. Rather than pairing, they required at least a 20-minute weekly code review with an office-mate.
- Agile database schemas. Problem: RDBMS is rigid, but schemas evolve. Solution: build agile schema features and tools to manage change.
Lessons learned: Good:
- Agile practices help keep technical debt low.
- Build tools to support RDBMS and large codebase.
- Pull in senior people to help design and adoption.
- Cost of absorbing API changes is paid by the application teams, but benefits accrue to the business.
- It's hard to get feature design right (to balance flexibility and focus).
- The business had trouble understanding the costs of release management. (Branches made the whole thing even crazier; he described a "London subway" map they created to show all the paths.)
- People issues - don't go into denial.
- Weren't able to tell QA what the test suites did, so there was overlap between the automated tests and manual testing.
- Be humble - the platform needs the app and vice versa.
- Build reusable platform technology
- Use agile practices to cope with change
- Work with "eyes wide open"