What was more interesting about this release was the way that the community handled the decision-making surrounding a relatively minor performance feature: concurrent generation of new values for identity columns.
The feature went through the typical Derby development cycle: a developer, interested in the problem, created a proposal for fixing it; the patch was reviewed and discussed; feedback was addressed; the patch was committed.
Somewhat later, near the point when it was ready to be released, other developers in the community were running certain complex test suites that aren't routinely run, and these test suites were not performing well.
It wasn't obvious what was causing the test suites to mis-behave. When test suites get sufficiently complicated, diagnosing their behaviors can be as hard or harder than diagnosing the behavior of the actual product. We have lots of practice diagnosing the behaviors of the main product code, and over time we've built all sorts of debugging and diagnosis hooks into that code to assist with analysis. But tests generally are rather leaner in this area, and it's hard to tell what's going on when a complex, unfamiliar, and rarely-run test fails: is there a real problem in the product? Or is this a weak test, which was accidentally passing in the past because it wasn't written quite carefully enough?
The Derby community responded very well to these challenges, I feel.
There was no rush to judgement, no finger-pointing, no blaming. Instead, different members of the community studied the new behaviors, constructed theories, ran experiments, offered suggestions, and considered the ideas of others.
As time passed, the first release candidate missed its schedule, then was withdrawn from consideration. The suspect feature was backed out from the codeline, and testing continued. It was very hard to tell: was the new behavior more stable? Or about the same?
After considerable time, the product was felt to be ready for release, and the second release candidate was released this week.
Even though I had only a minor part in this process, I was fascinated to be involved. At a Derby community luncheon during the Oracle Java conference earlier this month, I attempted to sum up my observations about what had occurred to the group at large as follows:
- Software is hard
- We made a change
- Something new and interesting happened in the software
- We talked about it as a community
- Lots of people learned new things about the software
- We addressed the problem, and moved on
I know that it was quite painful for some of the participants who were more closely involved in the effort, but from my point of view, this was software engineering at its finest: a team of dedicated and talented people collaborate on an extremely complex undertaking and, together, overcome obstacles and deliver a strong new release.
Congratulations Derby on Derby 10.8.2.2!
No comments:
Post a Comment