William C. Wake's Blog

Agile '05 conference, part 2

Delivering APIs in an Agile Context, John Major

Tensions:

• Stable APIs vs. agile change
• General features vs. "Do the simplest thing that could possibly work"
• Frameworks vs. global refactoring
• Framework design vs. features

Unique practices:

• 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.

Bad:

• 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.)

Ugly:

• 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.

Summary:

• Build reusable platform technology
• Use agile practices to cope with change
• Work with "eyes wide open"

Comments

• I liked this combination:

  Tried having platform developers work on applications, but it didn't work so well.
  Cost of absorbing API changes is paid by the application teams, but benefits accrue to the business.

  So basically, you are saying that it's OK to do anything you can to API as long as you are not the one that needs to work overtime to change the code that uses it. This is simply ridiculous. How about projects that have no application teams? How about projects that have more combined application devs than platform devs? You are talking about the right hind leg of a dog (which is not the most important leg) shooting all other legs. Way to do, agile.
  And all of that is said from the point of view of a platform dev that has four application teams above him. At most, we make functions @deprecated, but almost never break APIs. And if we do, the price for everybody (including us that need to invest huge amount of time helping application teams) is quite high.

  Posted by: kirillcool on August 25, 2005 at 05:12 AM

• I think you should read it the other way around. They were actively looking for ways to ensure that platform developers understood the problems of application developers, and tried something that didn't work as well as they'd hoped (transplanting developers).

  You write,
  "So basically, you are saying that it's OK to do anything you can to API as long as you are not the one that needs to work overtime to change the code that uses it. This is simply ridiculous." It is ridiculous, and not what I'm saying at all. They were sensitive to that problem (as any platform group that wants to be around for a while must be).

  The issue of costs of API changes is a generic one for any platform group, and has nothing to do with agile per se.
  It's also tied in to the economics of reuse. Suppose every application has its own file browser, and the platform group finally standardizes one. Each development group looks at it and says, "we already have one, why would we want to spend the time putting this in?" But it turns out the benefits are to the business, who would like it all standardized so they can explain it once and not be confused by all the variations.

  
  "At most, we make functions @deprecated, but almost never break APIs." Yes, that's one of those prices of being a platform. (Java's got the same thing going - the old event model may never go away.)

  Posted by: wwake on August 26, 2005 at 03:15 AM

This work is licensed under a Creative Commons License.