Wednesday, October 20, 2010

Virtual Seminar: "Systematic Oracle SQL Optimization in Real Life"

On November 18 and 19, I’ll be presenting along with Tanel Põder, Jonathan Lewis, and Kerry Osborne in a virtual (GoToWebinar) seminar called Systematic Oracle SQL Optimization in Real Life. Here are the essentials:

What: Systematic Oracle SQL Optimization in Real Life.
Learn how to think clearly about Oracle performance, find your performance problems, and then fix them, whether you’re using your own code (which you can modify) or someone else’s (which you can not modify).
Who: Cary Millsap, Tanel Põder, Jonathan Lewis, Kerry Osborne
When: 8am–12n US Pacific Time Thursday and Friday 18–19 November 2010
How much: 475 USD (375 USD if you register before 1 November 2010)

The format will be two hours per speaker: an hour and a half for presentation time, and a half hour for questions and answers. Here’s our agenda (all times are listed in USA Pacific Time):

Thursday8:00a–10:00aCary Millsap: Thinking Clearly about Performance
10:00a–12:00nTanel Põder: Understanding and Profiling Execution Plans
Friday8:00a–10:00aJonathan Lewis: Writing Your SQL to Help the Optimizer
10:00a–12:00nKerry Osborne: Controlling Execution Plans (without touching the code)

This is going to be a special event. My staff and I can’t wait to see it ourselves. I hope you will join us.

Thursday, October 7, 2010

Agile is Not a Dirty Word

While I was writing Brown Noise in Written Language, Part 2, twice I came across the word “agile.” First, the word “agility” was in the original sentence that I was criticizing. Joel Garry picked up on it and described it as “a code word for ‘sloppy programming.’” Second, if you read my final paragraph, you might have noticed that I used the term “waterfall” to describe one method for producing bad writing. Waterfall is a reliable method for producing bad computer software too, in my experience, and for exactly the same reason. Whenever I disparage “waterfall,” I’m usually thinking fondly of “agile,” which I consider to be “waterfall’s” opposite. I was thinking fondly of “agile,” then, when I wrote that paragraph, which put me at odds with Joel’s disparaging description of the word. Such conflict usually motivates me to write something.

In my career, I’ve almost always had one foot in each of two separate worlds. These days, one foot is in the Oracle world. There, I have all my old buddies from having worked at Oracle Corporation for over a decade, from companies like Miracle and Pythian, the Oracle ACEs and ACE Directors, Oracle OpenWorld, ODTUG, and a couple dozen or so user groups that I visit every year. The other foot is in the business of software. There, I have colleagues and friends from 37signals and Fog Creek and Red Gate and Pragmatic Marketing, the Business of Software conference, and the dozens of blogs and tweets that I study every day in order to fuel a company that makes not just software that meets a list of requirements, but software that makes you feel like something magical has been accomplished when you run it.

In my Oracle world, agile is a dirty word. I have to actually be careful when I use it. To my Oracle practitioner colleagues, the A-word means, as Joel wrote, “sloppy programming.” In my business of software world, though, “agile” means wholesome golden goodness, an elegant solution to the absolutely most difficult problems in our field. I’m not being facetious one little bit here, either. The two most important influences in my professional life in the past decade have been, far and away:
  1. Eli Goldratt’s The Goal: A Process of Ongoing Improvement
  2. Kent Beck’s Extreme Programming Explained: Embrace Change (2nd Edition)
Far and away.

I don’t mention this among most of my Oracle friends. I don’t blurt out the A-word to them, any more than I’d blurt out the F-word at my parents’ dinner table. To talk with my Oracle friends about the goodness of “A-word development” would go over like an enthusiastic hour-long lecture on urophagia.

A lot of really smart people are very anti-“agile.” I’m pretty sure that it’s mostly because they’ve seen project leaders in the Oracle market segment using the A-word to sell—or justify—some really bad decisions (see Table 1). So the word “agile” itself has been co-opted in our Oracle culture now to mean sloppy, stupid, unprofessional, irresponsible, immature, or naive. That’s ok. I’ve had words taken away from me before. (Like “scalability,” which today is little more than some vague synonym for “fast” or “good”; or “methodology,” which apparently people think sounds cooler than “method.” ...Ok, I am actually a little angry at the agile guys for that one.) That doesn’t mean I can’t still use the concepts.

Table 1.
What people think agile meansWhat agile means
No written requirements specification; therefore, no disciplined way to match software to requirements.You write your requirements as computer programs that test your software instead of writing your requirements in natural language documents that a human has to read and interpret to re-test your software every time a developer commits new source code.
No testing phase; therefore, no testing.You test your software before every commit to your source code repository, by running your automated test suite.
No written design specification; therefore, developers just “design” as they go.You iterate your design along with your code, but design changes are always accompanied by changes to the automated test programs (which, remember, are the specification).
Rapid prototyping always results in the production code being a fragile—well—rapid fragile, prototype.When you can’t know how (or whether) something will work, you build it and find out—but only the parts you know you’ll really need. You use the knowledge learned from those experiences to build the one you’ll keep.

Agile is not a synonym for sloppy. On the contrary, you're not really doing agile if you’re not extraordinarily disciplined. I think that is why a lot of people who try agile hit so hard when they fail. I hope you will check out Balancing Agility and Discipline: A Guide for the Perplexed, coauthored by Barry Boehm (yes, that Barry Boehm) if you feel perplexed and in need of guidance.

As with any label, I hope you’ll realize that when you use a word that stands for a complex collection of thought, not everyone who hears or reads the word sees the same mental picture. When this happens, the word ceases being a tool and becomes part of a new problem.

Friday, October 1, 2010

Brown Noise in Written Language, Part 2

Here is some more thinking on the subject of brown noise in written language, stimulated by Joel Garry’s comment to my prior post.

My point is not an appeal for more creative writing in the let’s-use-lots-of-adverbs sense. It’s an appeal for clarity of expression. More fundamentally, it is an appeal for having an idea to express in the first place. If you have an actual idea and express it in a useful way, then maybe you've created something that is not spam (even if it happens to be a mass mailing), because it yields some value to your audience.

My point is about being creative only to the extent that if you haven’t created an interesting thought to convey by the time you’ve written something, then you don’t deserve—and you’re not going to get—my attention. (Except you might get me to criticize your writing in my blog.)

What Lanham calls “the Official Style” is a tool for solving two specific problems: There’s (1) “I have no clear thought to express, yet I'm required to write something today.” And (2) “I have a thought I'd like to express, but I'm afraid that if I just come out and say it, I'll get in trouble.” Problem #1 happens, for example, to school children who are required to write when they really don’t have anything in mind to be passionate about. Problem #2 happens to millions who live out the Emperor’s New Clothes every day of their lives. They don’t “get” what their mission is or why it’s important, so when they’re required to write, they encrypt their material to hide from their audience that they don’t get it. The result includes spam, mission statements, and 98% of the PowerPoint presentations you’ll ever see in your life.

I’m always more successful when I orient my thoughts in the direction of gratitude, so a better Part 1 post from me would have been structured as:
  1. Wow, look at this horrible, horrible sentence. I am so lucky I don't have to live and work in an environment where this kind of expression (and by implication, this kind of thinking) is deemed acceptable.
  2. I highly recommend Lanham's Revising Prose. It is brilliant. It helps you fix this kind of writing, and—more importantly—the kind of thinking that leads to it.
  3. I’m grateful for the work of people like Lanham, Fried, Heinemeier-Hansson, and many others, who help us understand and appreciate clear thinking and courageous writing.
Writing is not just output. Writing is an iterative process—along with thinking, experimenting, testing—that creates new thought. If you try to use the waterfall approach when you write—“Step 1: Do all your thinking; Step 2: Do all your writing”—then you’ll miss the whole point of how writing clarifies and creates new thought. That is why learning how to revise prose is so important. It’s not just about how to make writing better. As Lanham illustrates in dozens of examples throughout his book, revising prose forces improvement in the writer’s thinking, which enriches the writer’s life even more than the writing, however tremendous, will enrich the reader.