An Exclusive
Interview with Steven Feuerstein

Here is an indepth, personal interview with Steven Feuerstein, the author of several books on how to deal with PL/SQL programming against Oracle databases; a powerful tool in our day-to-day work with Oracle:

A short bio on Steven Feuerstein:

Steven Feuerstein is considered one of the world's leading experts on the Oracle PL/SQL language, having written ten books on PL/SQL (all published by O'Reilly Media).

Steven has been developing software since 1980, spent five years with Oracle (1987-1992) and has served as PL/SQL Evangelist for Quest Software since January 2001.

He is also an Oracle ACE Director. He writes regularly for Oracle Magazine, which named him the PL/SQL Developer of the Year in both 2002 and 2006.

Steven lives in Chicago with his wife, Veva.

Hundreds of thousands of copies of this book have helped countless developers take full advantage of the Oracle PL/SQL language.

The following interview with Steven Feuerstein is, as said, totally exclusive to this website, so please enjoy:

Database Design Resource:

How did you become involved in PL/SQL?

Steven Feuerstein:

Before diving in, I have two confessions to make:

first, I have gotten to be one of the most narrowly specialized technologists in the world. I really just know one thing: PL/SQL. Fortunately, I know that one thing pretty well. Even more fortunately, Oracle has done a splendid job of designing, building and enhancing that language.

Sure, I used to write Fortran, but these days if you ask me about anything outside of PL/SQL you will draw a blank or an answer you really shouldn't trust - even when it comes to "straight" SQL!

Second confession: I am not really much of a technologist, and certainly not a computer scientist. I took three 101 (introductory) courses on programming in college, and that is it for formal education.

I have come to recognize over time that my strength is not that I am an amazing computer scientist sort of guy, but that I am an effective communicator.

People seem to be able to actually read my stuff, understand it and then learn from it. And it hasn't hurt, from what I have been told, to let my oddball sense of humor actually make an appearance in my books...

Having said that, I got my beginning with Oracle as a presales person. I spent a couple of years following salespeople around to accounts and doing the dog-and-pony shows for them with SQL*Plus, SQL*Forms, etc.

I can still remember my first public seminar for Oracle. Basically, what we were doing back in 1987 was running SQL*Plus scripts and saying "Isn't this language amazing?"

So I was given the standard script from Oracle for the presentation, drove up to Milwaukee with my boss, John Cordell, and got up in front of about 30 people to wow them.

Now, I am a compulsive tinkerer, so I decided that there were some ways I could improve the script. Unfortunately, I am also not the most disciplined person so there were two bugs in this canned script! It was quite embarrassing, but I survived, and John was very nice about it.

Presales was interesting and sometimes exciting, but programming was way better, so I would constantly dabble with the Oracle tools, building little apps for my co-workers to use. This developed into TeamSell, a sales support application that caught the eye of Mike Fields, head of US Sales in the early '90s. I was drafted to join a small dev team and we started building some very cool SQL*Forms apps to support the US salesforce.

Then Larry (Ellison) canned Mike (USA sales missed its "nut" by a small amount that year) and I was told to go back out on the road to help sell Oracle. I said no thanks, took the first consulting job I was offered, and ended up spending three years at McDonald's headquarters in Oak Brook.

While there, I saw an appeal on Compuserve for Oracle authors and I thought "Why not? I can write." So I wrote that first book, Oracle PL/SQL Programming, which was the first independent text on PL/SQL. To say that the publication of "OPP" changed my life would be a cliché, but it is no less valid for being a cliché.

From that point on, I was virtually a full-time student and practitioner of the PL/SQL language, researching, writing, teaching, building code, etc.

Database Design Resource:

Can you comment on the development of PL/SQL through the times?

Steven Feuerstein:

Oddly enough, I believe that PL/SQL is as wonderful a procedural language as it is in part because Oracle did not design the bulk or foundation of the language. Too many software shops have the belief that "We can do it better than anybody else."

Now, I think it is demonstrably true that Oracle is the absolute best at relational database technology. Would that mean that they have the necessary expertise to build an excellent mouse-driven UI development tool? They thought so back in the Oracle Forms 4.0 days - and they were wrong, with astonishing results for their bottom line: Oracle lost substantial revenue to PowerBuilder, which got the client-server UI development paradigm right.

Once Oracle decided that it needed a programming language to complement SQL, they could have said "We can build programming languages better than anyone else."

Almost surely they would have been wrong and we would have ended up with a language more like Transact-SQL, originally from Sybase and clearly lacking much of the depth and power of PL/SQL. Instead, Oracle said: "Hey, there's been lots of research and work in this area. Let's see what others have done. Maybe we can use that language as a model." And that's what they did. Apparently, it came down to PL/1 or Ada, and Ada was in the end chosen as the model for PL/SQL.

Because of that, PL/SQL started as a relatively mature language, at least in terms of structure and syntactic power.

From that starting point, Oracle has seen PL/SQL as a critical layer of technology in its stack, and committed substantial resources to improving the language. I had a scare around the time of the release of Oracle8i, when Oracle announced the ability to write Java Stored Procedures in the database. Would Oracle, as the rumors claimed, jettison PL/SQL in favor of Java?

Ha! That would have been one heck of a mistake and the moment (and panicky feelings) passed quickly. PL/SQL is here to stay, Oracle continues to invest substantial resources in making it faster, easier, better.

Let us continue the interview with Steven Feuerstein:

Database Design Resource:

Where do you see PL/SQL going into the future?

Steven Feuerstein:

Pretty much what I just said: PL/SQL is going to be around as long as the Oracle database is in use. Many years, in other words. Decades. Having said that, we should acknowledge that PL/SQL is not an "ascendant" language. We don't see hundreds of thousands of new PL/SQL developers each year, except perhaps in places like India and China. It is not a "cool" language.

But that's OK. I expect that anyone specializing in PL/SQL today will have many more years of productive and lucrative employment. In fact, I expect that over time, PL/SQL developers will be a scarcer "commodity" and you will be able to negotiate a higher rate/salary than Java or .Net counterparts with a similar level of expertise.

As for the language itself, I hope you won't be offended if I quote from my blog:

On Tuesday this past week (March 24, 2009), I had the honor of spending some time at Oracle headquarters with two guys from the PL/SQL Team -- Charles Wetherell, the brains behind the optimizing compiler, and my long-time sparring partner Bryn Llewellyn, the public face of the team. I make the pilgrimage to HQ every year or so to share PL/SQL stories, meeting different team members each time.

I talk about what I am doing with PL/SQL and what I see out there in the big world of PL/SQL developers. They talk about what they are doing with the language, and where they see it going. They usually even pretend to give consideration to my viewpoints!

Aw, just joking. They are most respectful.

Now that Oracle Database 11g Release 2 is well into its Beta Program, most of the developers at Oracle HQ are hard at work on the end-game activities -- while some are already starting to plan the content of the next major release. It was great to have the chance to talk, strictly off the record, with Charles and Bryn about their ideas for the next big steps in PL/SQL, and to put forward some of mine.

And while I cannot go into any details, I can tell you that it is very clear that Oracle remains committed to supporting and enhancing the PL/SQL language in very substantial and, in at least one case, for me, quite surprising, ways.

I can also report that the team generally pays attention to input from their users (PL/SQL developers). Not only that, but the ideas proposed and voted on at ILovePLSQLAnd.net are treated with the utmost consideration. So please, please, please.... if you have not yet visited this website, please do immediately and vote on the PL/SQL enhancements you feel would benefit you the most. When Oracle Database 11g Release 2 becomes generally available, I will update the list on ILovePLSQLAnd.net to show what has been implemented.

And, as always after a meeting with my friends on the PL/SQL team, I am reminded of two things:

1. How glad I am that we have people of their caliber (real computer scientists) planning out and implementing changes to PL/SQL - and not people of my caliber (that is, largely self-trained and quite amateurish by comparison).

2. That for many years to come, PL/SQL will continue to be a truly fine language in which to write software and implement business requirements.

So, happy coding, my fellow PL/SQL developers! Rest assured; our future selves will be more productive and ever more pleased with the language with which we spend so much of our time.

Database Design Resource:

What is your take on the "need" from some programming environments for defining objects instead of "ordinary" tables and rows?

Steven Feuerstein:

Well, this is one of those areas in which I must admit to some ignorance.

I have never gotten trained up in object-oriented thinking. I spent about a month working with Java intensively, a few years ago, and all it confirmed for me was that, yes, it was possible to use an OO language like a procedural language.

So what is my take on this? I will answer that in a very general way: programming languages are tools, to be used to meet our objectives (which are, roughly, to: write correct code, write code that is fast enough, and write code that is maintainable).

Different tools have different strengths and weaknesses, and we should all strive to use the right tool (match strengths to challenges) at the right time.

I have no doubt that OO can be very helpful, even within Oracle backend code. I do think that every PL/SQL developer should have a working familiarity with Java so that they are not scared by those squiggles.

Beyond that, it would also be good to have some basic understanding of object orientation.

Database Design Resource:

What is your relationship to Oracle today?

Steven Feuerstein:

I like to think of myself as a symbiotic mutualist, attached to and extracting a living from the enormous hulk of Oracle technology.

I benefit greatly from Oracle technology, my readers benefit from me, and I do think that Oracle does get some benefit from me, as well.

I decided to make my title at Quest "PL/SQL Evangelist." Now, clearly, such a position really belongs at/inside Oracle, but the closest Oracle has to a PL/SQL evangelist is Bryn Llewellyn, PL/SQL Product Manager. Bryn sure knows PL/SQL, much better than I, and he does some evangelism, but he can't do it all, so I contribute in my own way, helping developers make the most of this language.

There is, however, no special relationship. I am not on any kind of inside track for information. Bryn will not disclose to me any details about Oracle12, for example, that he would tell anyone else or at a public venue. I have to apply to join beta programs like everyone else, submit my OOW presentations for approval like everyone else.

I like it that way. I don't want special treatment. Or, to be more accurate, I want to be treated special by Oracle precisely and only because I am a PL/SQL developer. :-)

Database Design Resource:

PL/SQL has indeed changed how we can use Oracle. What is THE most important feature?

Steven Feuerstein:

I tell my students that the single most important feature added to Oracle since Oracle8i is bulk processing (BULK COLLECT and FORALL).

If you are not using these statements for all multi-row SQL operations, especially DML, then you are missing out on some of the most powerful performance features of PL/SQL. And, of course, to use them you have to know about collections:

Collections would be the second most important feature. If you are not comfortable using collections, then you are using PL/SQL as it existed more or less in version 7 of the Oracle RDBMS. Everyone who writes PL/SQL should be using collections routinely, to solve all sorts of different problems.

So...buy my books, attend my trainings...well, that's a bit self-serving. So instead, just head over to PL/SQL Obsession and click on the "Trainings, Seminars and Presentations" link. You can then download all of my training materials, plus supporting code examples. These resources will definitely help you "jump start" your knowledge and use of these features.

Database Design Resource:

You do lectures around the world on PL/SQL and related issues: where can interested parties find you?

Steven Feuerstein:

I try to maintain a current schedule at ToadWorld. So check there for announcements of trainings (Oracle sponsors my trainings as part of their "Celebrity Series" - I kid you not; I will be in Istanbul, Copenhagen and Helsinki for Oracle this spring)and presentations.

Beyond that, I attend all the major US Oracle conferences (Collaborate, Oracle Open World, ODTUG and my all-time favorite Oracle PL/SQL Programming, a two-day, nothing-but-PL/SQL conference sponsored by ODTUG) and usually also make it out to the UKOUG conference in December.

I also love to present (either/both short presentations and full day trainings) to regional and local Oracle User Groups.

And I do on-site trainings as well. So if anyone reading this is interested in having me speak to your members or developers, drop me a note at steven at stevenfeuerstein dot com (Editor's note: masked to avoid spam...).

Database Design Resource:

On a personal note, Steven: You like to travel, and so do I. But is it hard for you to find the time for it?

Steven Feuerstein:

How do I make time for travel? 99% of my travel is driven by PL/SQL and Quest activities, so I make time for it as a part of my job (I have been a full-time employee of Quest Software since January 2001, but I also do my "own thing").

When I have the opportunity to travel solely for personal reasons, I almost always visit with family (I have four sisters, three in the NY area where I grew up, and my parents live in Florida) or head down to Puerto Rico.

Since 1995 (when I published the first edition of OPP), I have traveled to more than 25 different countries, sharing my thoughts on PL/SQL. Whenever I go to a new city, I like to seek out the finest art museum and soak up the creative energies of the artists. I feel privileged to have been able to see so many incredible works of art over the years.

I was in Prague in late May 2006 and took an extra day past my trainings to wander the city. Prague is a beautiful place and I encourage you all to visit, but what I found most incredible were the sidewalks. I think the sidewalks caught my attention so dramatically because my views on ornamentation in architecture and public space generally have been changing.

I used to be a "form follows function" kind of guy: I appreciated the clean lines of modern design and scorned elaborate designs that didn't seem to really do anything. If it isn't "doing" anything, then why waste time, effort and money building it?

Then I came across the writings of the architect Christopher Alexander. Alexander has developed a healthy dislike for modern architecture and believes that it is possible to come up with a "pattern language" that is universal and can help us design and build structures that improve our quality of life on multiple levels.

Alexander has in recent years published his "Nature of Order" series of books, which argue for the place of ornamentation in our architecture and other aspects of human creativity. I have come to agree and urge you to check out his writings, especially: The Timeless Way of Building and the Nature of Order series.

You can read more about - and see - these sidewalks by visiting my blog.

Database Design Resource:

Do you have any new book projects?

Steven Feuerstein:

I am compulsive. There is no doubt about it. And one of my compulsions is to create new things.

I think that the creative impulse is one of the key criticisms of sentient creatures. So prove you are sentient: create something new!

As a result, I start lots of things, even get them launched, but then often don't have the bandwidth to follow through, which is very frustrating.

I definitely got compulsive around books on PL/SQL. I have written a total of ten texts on PL/SQL, and that was probably a few too many. Why do I say that? Books, like code, hang around for a long time and therefore need to be maintained. Ten books are lots of books to maintain (new editions).

And that is what I do these days concerning books: update my editions. Sometimes this involves lots of rewriting (as with the second edition of Oracle PL/SQL Best Practices).

I am at this moment finishing up edits on the 5th edition of the big OPP book, covering all/most PL/SQL features up through Oracle11g Release 2. Our main challenge with that book these days is to keep the page count at no more than 1000.

When I signed my first contract with O'Reilly, it said that I should write a book of about 400 pages. I was worried that I couldn't find enough to write about - PL/SQL is, after all, a fairly straightforward language (especially Version 2, with Oracle7). 1200 pages later we had to cut 400 pages for that first edition.

And if I'd been really smart I would have immediately repurposed that content into another book: Oracle PL/SQL for Oracle Forms Developers. 'Cause that's what we cut out: guidelines for writing PL/SQL in Oracle Forms and, secondarily, Oracle Reports.

Ah well. That would just have been another book to maintain.

Besides my books, I am working on the following projects:

ILovePLSQLAnd.net (a communication channel for PL/SQL developers direct to the PL/SQL Product Manager), Quest Code Tester for Oracle (the very best automated testing tool for PL/SQL code), the PL/SQL QuizDB (not yet available; I am building a repository of hundreds and then thousands of PL/SQL quizzes, which I hope to publish as a Daily PL/SQL Quiz), Quest Error Manager (freeware error management utility for PL/SQL, available at ToadWorld, Quest CodeGen Utility (a Design Pattern factory tool that generates table APIs, among other things, available at ToadWorld, my Oracle Magazine Best Practices column.

....hmmm, is that it? Oh yes, the rest of my life: family, exercise, ranting about the injustices of the world, you know, all that sort of stuff.

Database Design Resource:

Finally, Steven: Can you share some big mistake(s) you made, that you can now look back on and laugh at :-).

Steven Feuerstein:

I very much like this question - precisely because it assumes that I have made mistakes, big and small, and am willing to be open about that.

I can still remember working back in 1997 as a consultant in a downtown Chicago firm. My first book had been out for a couple of years. I was asked to build a generic error manager for the application, and so I did that. Then I went off on another assignment for a couple of weeks.

When I returned and asked how the tests of my error manager had gone, their response shocked me to my core. They said: "Test your code? We don't need to test code written by Steven Feuerstein!" (or something along those lines).

My mouth hung open. I had this feeling that I needed to get away, quickly. What a crazy idea! So what if I write a book that people really like because they can understand what the heck I am saying and they like my sense of humor (Editor's note: Steven's books are entertaining to read). That doesn't in any way increase the likelihood that I would also be a good programmer. And it sure as heck doesn't mean that I am a great programmer.

I feel that I am able to step back and take a reasonably objective look at my own programming skills and code. Here's what I see: A classically dangerous programmer. Clever, figures things out quickly, can juggle lots of complex structures "in memory", loves to solve problems and create things. That all sounds pretty good, right?

Unfortunately the downside is that I do things too quickly, am not disciplined (enough), am desperately optimistic that my code works even though I know it must be full of bugs.

I am also a massive hypocrite. I routinely violate any number of my best practices. I even occasionally use a GOTO in my programs!

Maybe I shouldn't admit such things. It might tarnish my reputation. Well, that's fine by me. I think that reputations should be tarnished on a regular basis, should be subjected to scrutiny and criticism. Then they can be polished up again to a fine shine if such a shine is still deserved.

I will tell you about a mistake I made a long time ago, that has stuck firmly in my mind, and serves as a reminder that you can always take a best practice too far.

After I wrote my first book, Oracle PL/SQL Programming, and was overwhelmed by the positive response, I decided (of course) to write a second, "advanced" book ( Advanced Oracle PL/SQL Programming with Packages). I stressed in this book the need to avoid hard-coding of...well, anything, but especially literals.

I sought to implement this principle thoroughly in PL/Vision, the library of code that accompanied the book (and is still available on ToadWorld).

In my drive to ban literals from my code, I had built a package like this:

PACKAGE plv
IS
   c_true  CONSTANT BOOLEAN := TRUE;
   c_false CONSTANT BOOLEAN := FALSE;
END plv;

and then in my code (and throughout my book), you would see statements like this:

DECLARE
   l_salary_increased BOOLEAN := plv.c_false;

Made perfect sense to me - at first.

I can still remember very clearly the day I took a break from the final editing phase of the book, to walk up Western Avenue (the longest street in Chicago, in case you were wondering).

Suddenly, as if a lightning bolt had struck me, I realized that this idea of hiding TRUE and FALSE behind named constants was an a ct of lunacy or, to be more accurate, the sort of thing a fanatic would do once he'd completely lost his common sense.

I hurried home, did a global search and replace of book text and code to reinstate the Boolean literals, and then we went to print.

OK, maybe that doesn't really count, because I caught the mistake before anyone saw it. I can assure you, however, that not only have I made many mistakes over the years (covering every single classic mistake ever made by a programmer), but I continue to do so.

Having said that, I will give myself a little credit: I am constantly pushing to improve the quality of the code I write and to reduce my hypocrisy. Perhaps someday I will live up to my own expectations.

Database Design Resource:

Steven, thank you for taking the time to give the readers of this website a closer insight into Oracle PL/SQL programming, as well as getting to know you a little better!

This has been a personal interview with Steven Feuerstein, one of the top Oracle PL/SQL Programming experts in the world today: Much appreciated!

Return to Database Design Home