While working on the second edition, I am mostly pleased with what I did over four years ago, it has held up well. And due to the plethora of examples in the book - it is very much self correcting. One of the problems a second edition like that could seriously run into is that the author knew the first time how something worked and as they are reading it - still believe it to work that way. Only it doesn't and they don't catch that -- because they didn't demonstrate it. Things change. It does makes it hard to plot how long it will take - because what seems like "this will be a simple couple of pages" turns into an entire afternoon.
Case in point, in Expert One on One Oracle, pages 177-180 I describe this phenomena "delayed block cleanout". Then on page 191, I come back and show how it can trigger an ORA-01555. Only it doesn't anymore. I mean, it should in theory - but I cannot get it to anymore. I try everything - a 2 MB undo tablespace (I wanted to use automatic undo management because I believe we should be, I dig that feature a lot) of fixed size. A 4 MB buffer cache (about 500 blocks). An 8,000 block table - update the first row on every block (guaranteeing myself that I'll have delayed block cleanout). Open a cursor but don't fetch. Do the small transactions off to the side - overwrite the undo many times. Fetch a row and.. bummer, it works. It still works (which means it succeeds, but I want it to fail) if I do the transactions in another session. It just keeps working and working. I cannot get it to 1555. Wrote to Jonathan Lewis to get some ideas. Finally - got it, do the above, dirty the table, open the cursor and then in FIVE other sessions do some work, come back to the original session and fetch a row - bam, ORA-01555 (never was so glad to see one in my life!).
Turns out in 10g, they've changed some things - ORA-01555's will be rarer and less frequent - the cases where they come about due to delayed block cleanout are fewer - takes more things happening at once (so they are not gone). But, had I just described a phenomena and been done with it - and not had an actual method that said "if you do A, B, and C you'll see D" - the book would have been in error. So many of the examples are like that.
So yes, working on the second edition is tough. I've found one or two technical inaccuracies in the book (poorly phrased sentences, in hindsight I know what I mean but it could be read wrong). They are getting corrected but I'm sure new ones are being added. And, so much has changed. Many new background processes. Memory management is radically different.
But the "quality process" I follow is "it isn't so until I see it". I know I'm going to have really smart people reading this under a microscope, I cherry picked my review team this time - so peer review is big in this 'quality' thing. Criticism is something that has to be accepted willingly and freely. Oh - I'll put up my side of the argument when appropriate (don't worry about that) but definitely concede the point more often than not. And the criticism can be brutal, but you cannot take it too personally. Actually on the technical material, I tend to not take it personally at all. You can say "that's not a very smart way to show that", "that's way overly complicated, you should do it like this", "here is a better way to show that", "that is just totally wrong and here is why" (and believe me, they do, I do myself when reviewing - you cannot just say "that is totally wrong" though, you have to follow it up with "and here is why")
So, I think quality is about going the extra mile to verify that what you say or do is mostly "correct". Off the cuff work is the low quality stuff - I think the stuff we print and publish needs to take a long time to produce (must be tested), must be peer reviewed (that is what I love about asktom - that is a peer review by 10's of thousands of people), must be criticized. You would think for example that text that was verbatim from the first edition of the book - already printed and accepted - and still true would be sacrosanct, beyond reproach. Not a chance, it receives as much criticism as the rest. Chapter Two - over 100 comments (criticisms) and it was small (13 pages, boy, I cannot wait for the Tables chapter to come back - at 74 pages)
On the "Why" blog - I received this comment:
How to "Question authority" - Without screwing up your appraisals?
That is a clear indication that there is a less than quality process going on there. If you fear questioning authority, that is a big problem. Anyone in a technical environment who says "Because I said so" (caveat, as a parent of a 12 and 9 year old, we are of course exempt from this rule applied to our children until they are living on their own!) or "I don't need to justify why", "I don't need to show you why, I'm experienced, just do it the why I say" - well, they are full of it. Run, don't walk, to the next project that comes along. That is not someone you want to learn from. I must admit, I've been rather lucky that way - I've always had good leadership to learn from, leadership that not only was willing to be criticized, but would say "ok, now, what's wrong with our plan".
I wish every web page had a link on the bottom that let us add a comment -- anonymously or not. Every web page. There are so many out there with just provably wrong statements on it that I'd love to leave behind a 3 or 4 line snippet of something that shows "no, that isn't quite right -- or isn't always right -- or is never even close to right".
Quality isn't something you get the first time all of the time, only through incremental refinement. Quality in our business, if I had to boil it down to an equation, might be:
Q = the SUM of ( hard work + peer review/criticism ) over incremental refinement
meaning it is a summation of (work+review)+(rework+review)+(rework...)... but is a series that converges rapidly if your review team is good.
In closing - am I harsh on people that don't indent their code ;) Hopefully in person I come off less harsh than I must in some writing. Yes, I believe indenting is important but even more so are my two rules:
1. The subroutine (also known as a "method") must fit on the screen from top to bottom (the declarations are allowed to scroll off the top but the entire body must fit). Anything bigger than that is too big to digest. I work on a 1600x1200 and a 1650x1080 screen - if I cannot fit your code on screen from top to bottom, I just won't even look at it.
2. There had better be some sort of logic explanation/comment in there unless it is so obvious my mother could figure it out. That is why when 'tuning' a query, I want the 'question' - not the query. I want to know what the goal is and not be influenced by your past attempts. I want to know what it is supposed to do before I look at how you did it.