I worked at Oracle from 1997 to 2005 for 3 years on the app server team in Portland and the last 5 on DBMS query execution in Redwood Shores. I had a good time there, made many friends and learned a lot.

They had an excellent process for functional and design specification reviews. Like many, I am wary of (too much) process but this wasn’t too much. It was just enough.

At a high level, you would write and then get a review for the functional spec. The review was an in-person meeting. Once that was resolved the process would repeat for the design spec. You were expected to write a good spec – it was better for one person (the author) to spend much time on it to avoid wasting time for the many readers. Many specs would be revisited long after the review because there is turnover and specs are easier to read than source code.

We used FrameMaker to write the specs on Solaris workstations. That was a long time ago. The functional spec I wrote for IEEE754 datatypes was more than 50 pages because I had to document every aspect of PL/SQL and SQL that would be impacted by it (there were so many functions to document). The design spec I wrote for a new sort algorithm was also quite long because I had already implemented the algorithm to collect performance results to justify the effort. The patent attorney copied much of that design doc into the patent resulting in a patent that might be more readable than average.

For each specification you setup a meeting a few weeks out and shared the spec with people who might attend the meeting. In many cases there was feedback via email or in person prior to the meeting that could be resolved before the meeting. But in some cases there was feedback that wouldn’t get resolved until the meeting.

It is important to split the functional and design specs, and their reviews. It helps with efficiency and the design review might change a lot based on the outcome of the functional spec review.

There are a variety of responses to the feedback, and all of that was added to an appendix of the spec (both the feedback and the response). Common responses include:

• good point
• I will change my spec as you suggest
• no thank you
• I disagree and will not change my spec as you suggest. Hopefully this isn’t the response to all feedback but some people like to bike shed and/or get in the way of progress. When I rewrote the sort algorithm, I used something that was derived from quicksort and quicksort implementations have worse than expected performance on some input sequences. The algorithm I used was far better than vanilla quicksort in that regard, but it didn’t eliminate the risk. However, the performance improvement over the existing code was so large (the white paper claims 5X faster) that I sad no thank you and the project got done. But I did spend some time doing the math to show how likely (or unlikely) the worst cases were. I needed a tool with arbitrary precision math to for that because the numbers are small and might have ended up using a Scheme implementation.
• good point, but
• I won’t change my spec, but I have a workaround for the problem you mention. For IEEE754 datatypes, a few people objected because a few infrequently and fading platforms for the DBMS did not have hardware support for IEEE754. My solution was to use functions for each IEEE754 operation that were trivial for platforms with IEEE754 HW support – things like double multiply_double(x, y) { return x*y } but could be implemented as needed on the platforms that lacked IEEE754 via a software implementation of IEEE754.