Where database blog posts get flame-broiled to perfection
Well, isn't this something. A real blast from the past. It’s heart-warming to see the kids discovering the revolutionary concept of writing things down before you start coding. I had to dust off my reading glasses for this one, thought I’d stumbled upon a historical document.
It’s truly impressive that Oracle, by 1997, had figured out you should have a functional spec and a design spec. Separately. Groundbreaking. Back in ’85, when we were migrating a VSAM key-sequenced dataset to DB2 on the mainframe, we called that "Part A" and "Part B" of the requirements binder. The binder was physical, of course. Weighed about 15 pounds and smelled faintly of stale coffee and desperation. But I'm glad to see the core principles survived the journey to your fancy "Solaris workstations."
FrameMaker, you say? My, my, the lap of luxury. We had a shared VT220 terminal and a line printer loaded with green-bar paper. You learned to be concise when your entire spec had to be printed, collated, and distributed by hand via inter-office mail. A 50-page spec for a datatype? Bless your heart. I once documented an entire COBOL-based batch processing system on 20 pages of meticulously typed notes, complete with diagrams drawn with a ruler. Wasting the readers' time wasn't an option when the "readers" were three senior guys who still remembered core memory and had zero patience for fluff.
I must admit, this idea of an in-person meeting to review the document is a bold move. We usually just left the binder on the lead architect's desk with a sticky note on it. If it didn't come back with coffee stains and angry red ink in the margins, you were good to go. The idea that you’d book a meeting weeks out... the kind of forward planning one can only dream of when the batch window is closing and you've got a tape drive refusing to rewind.
And this appendix for feedback... a formalized log of arguments. Adorable. We just had a "comments" section scribbled in the margin with a Bic pen, usually followed by "See me after the 3pm coffee break, Dale." Your "no thank you" response is just a polite way of saying the new kid fresh out of college who just read a whitepaper doesn't get a vote yet. We called that "pulling rank." Much more efficient.
When I rewrote the sort algorithm, I used something that was derived from quicksort...
Oh, a new sort algorithm! That's always a fun one. I remember a hotshot programmer in '89 who tried to "optimize" our tape-based merge sort. It was beautiful on paper. In practice, it caused the tape library robot to have a nervous breakdown and started thrashing so hard we thought it was going to shake the raised floor apart. His "white paper" ended up being a very detailed incident report. Glad to see yours went a bit better. And using arbitrary precision math to prove it? Fancy. We just ran it against the test dataset overnight and checked the spool files in the morning to see if it fell over.
And this IEEE754 workaround... creating a function wrapper to handle platforms without hardware support?
double multiply_double(x, y) { return x*y }
That's... that's an abstraction layer. A function call. We were doing that in our CICS transaction programs before most of you were born. It wasn't a "workaround," son, it was just called programming. We had to do it for everything because half our machines were barely-compatible boxes from companies that don't even exist anymore. It’s a clever solution, though. Real forward-thinking stuff.
All in all, it's a nice piece. A charming look back at how things were done. It’s good that you're documenting these processes. Keeps the history alive. Keep at it. You young folks with your "design docs" and your "bikeshedding" are really on to something. Now if you'll excuse me, I think I heard a disk array start making a funny noise, and I need to go tell it a story about what a real head crash sounds like.