“Stop Hiding From Your Planet” – Interview with Steven Feuerstein about Databases, PL/SQL, and Direct Positive Action

Some weeks ago, I did an interview with Steven Feuerstein for the DOAG RedStack magazine.

Steven has been a major inspiration for me during the past couple of years, both professionally and personally. He was one of the people who really encouraged me on my speaker journey and provided a lot of thoughtful and honest advice whenever I reached out to him.

Since the RedStack article is in German, only, I will provide the English version (with friendly permission of DOAG e.V.) here. I think what Steven has to say is worth being heard by a lot of people.

---

Samuel: Thank you Steven for taking the time to chat with us. Do you want to introduce yourself?

Steven: No, it’s an interview, you have to ask the questions (laughing)

Samuel: Okay, then I will make a short introduction: Steven is one of the most knowledgeable public figures and famous advocates when it comes to Oracle’s PL/SQL language.

Steven: I like to call myself a “popularizer”. Though many might find it hard to believe, I am not very technical, not a computer scientist. Sometimes I am referred to as “the father of PL/SQL” and I have to tell you if I created PL/SQL it would not be very good. But I seem to be good at communicating ideas and making developers laugh.

Samuel: “Popularizer” – I love that term! You also have written ten books on Oracle and PL/SQL, given hundreds of talks and keynotes around the globe, and continue to constantly share amazing content for database developers, for example with your biweekly “Feuertips” sessions (Insum Feuertips: PL/SQL tips with Steven Feuerstein).

So, how did you get started into software development?

Steven: I’m an old guy, I’m 63, and that means when I went to college computers were just seeping into the minds and lives of humans. It also means that you could fall into a decent job in programming without much formal training in computer science, which is what I did.

So I ended up taking a couple of classes in programming when I was in college. I think I started with ALGOL and then continued with LISP.

I just dabbled a bit with it and then had the opportunity to start working as a programmer in a research project on campus, which was in FORTRAN, so I basically stayed another year after graduation, working as a programmer.

I kind of fell into it and never had what you call a career plan, I never said to myself: first, I’ll get this job, then after a couple of years, I’ll be ready to do the next job. I moved from job to job, learned things, and eventually fell into a job at Oracle, again without any real plan.

Samuel: How did you pick up PL/SQL then?

Steven: By getting a job at Oracle Corporation in 1987! I’d been working as a consultant for a few years, mostly writing Fortran, and drifting into databases via System 1022 for DEC-10 computers.

I was super bored with where I was, so I started looking for a new job and came across something at Oracle Corporation (never heard of it) involving relational databases (never heard of them). I had no idea about relational databases, but I found an article on the 12 rules for relational databases, memorized them, went to interviews, and was eventually hired (I was never asked, throughout the entire process, what I knew about relational technology). That was even before PL/SQL, though I think they were already working on it.

I was a pre-sales person, which meant in 1987 that my job was to stand in front of an audience, run a couple of SQL statements, and make them excited about how you could easily order by a different column. The good old days!

It was kind of a harbinger of my career to come, which I suppose could be marked by creativity, willingness to try new things, and not being very disciplined or careful.

So I was handed a SQL script by my manager John Cordell to present, and he a=camne to watch me of course, because it was my first time ever doing a public seminar. And of course, I wasn’t satisfied with the script so I had to change it and make it more interesting. So I did that and made it more interesting, but also didn’t test it thoroughly. So in the middle of my first public seminar, running a canned script, it happened: press enter, run something, get an error. (laughs)

I fixed it on the fly, and I’ve never stopped doing that in the hundreds of presentations I’ve done since then. As I like to say: “Act now, perfect later.”

Except maybe you never get around to perfecting, you just keep acting/doing. And thereby avoid falling flat on your face.

Samuel: Amazing! Let’s focus a bit on PL/SQL: What is your favorite feature of PL/SQL?

Steven: First of all, generally, my favorite thing about PL/SQL is that Oracle really got it right in terms of integrating a procedural language with the database. They were very smart that they didn’t say “We can design programming languages better than anybody”, which is a really bad tendency among software companies. They think that because they can do software A, they also can do software B and C and D. And Oracle made that mistake several times and lost a lot of money because of it, but when it came to PL/SQL they looked at existing programming languages instead, to see if there was a model they wanted to follow. They eventually chose ADA, so as a result, we got a really well-structured language as a foundation, which they then let merge with the database. For example: You can take a for loop, go from one to ten and do X. But they extended that conceptually and syntactically, so for example you can do this loop for every row returned by a query. That is my broad favorite aspect of PL/SQL.

As a specific feature, I have to say: String-indexed collections are just the best! I guess they’re called maps in other languages – or associative arrays, which is their official name in PL/SQL as well. You can use them in so many creative ways, you can use them to reduce code redundancy – it’s just super cool!

Samuel: What is something you would like more people to know about database development in general or PL/SQL specifically?

Steven: In general, to just not be afraid of it. There has been a big push in modern software development away from relational databases, which is kind of understandable because all human beings strive for change and these relational database topics are seen as old school, not fancy. So there has been this general movement away, or let’s say, further up the stack. Which you can understand, because things get commodified at the lower level or hidden away, and then people don’t pay attention to them anymore. Usually with pretty bad consequences.

Like: One of the worst things Amazon ever did to the world, to our planet, is convincing us all that we should not have to pay for shipping. You’re a loser if you don’t go for free shipping. And yet, to make the entire transportation infrastructure of the global economy invisible and “free” turns out to be very bad news – for our planet, and therefore also for humans.

We have a similar situation here: If you disappear databases and you say they’re just commodities and that it doesn’t really matter and that you shouldn’t have to pay for them and shouldn’t have to pay attention to them – it turns out they are a pretty fundamental part of the stack and you have to pay attention to it if you want to optimize your applications and get the most out of your whole stack. I wish more people were aware of that.

Any successful application needs a solid database foundation. And you need a really great UI. But you need both of those, and the focus right now is nearly fully on great UIs, which is basically all driven by the smartphones.

So the way I would think about it is to convince developers that sure, you shouldn’t have to deal with databases, but you should have someone on your team who is a database expert. Every team should have a balance between UI and database people.

Samuel: You mentioned that smartphones had a big influence on how we see software development today. Can you elaborate on that?

Steven: To me, the most fundamental transformation that happened with computers is that the user of a computer used to be an employee of a company. So we built business software, the company bought the software, they would pay for training, people would learn how to use the UI and they might hate it, but they have to use it.

Then you have smartphones and suddenly everything is really your choice. And everybody can use it. And you can’t rely on training because people just need to be able to use it and so you have this powerful (and sometimes troubling) simplification of interfaces.

Since the creation of smartphones, there have been so many fundamental shifts in what drives software development and I think we are really just coming to grips with the impact of that.

One impact is that UI is now THE most important thing – and the database is so far away from user experience.

With smartphones, our software is also much more directly tied to culture. Business software was never so tightly attached to public culture, so it changed a lot slower, was a lot less individualized. Now everything is driven around that personal experience.

Samuel: Coming back to features of PL/SQL: If you could wish for one change in PL/SQL or one new feature: What would it be?

Steven: I think that would be full orthogonality. For example: I declare a variable to be a number, and instead of assigning a static number, I should be able to write a single-row select right there that fills the variable. So everywhere I have single value usage, I should be able to substitute that with a single value query. Things like that.

And they might even be working on that for version 23, I don’t know. They already took a big step in this direction in 21c, when they changed the iterator logic, and expanded it dramatically – that’s another example where they are kind of completing the language. More things like that would be very nice.

Samuel: That includes a boolean datatype in SQL, right?

Steven: Yes, that would be nice (laughs). Unfortunately, from my days inside Oracle, I can now see that (a) adding a brand new datatype to SQL is a lot of work and (b) the way they prioritize is to ask “Is there a way users can work around this missing feature?” If not, then higher priority. If so, then, well, there you go: work around!

But one very specific feature that I would love to have them add in is the ability to select bulk-collect into string indexed collections. Something like “select bulk collect into index by” and then give a column name (or several) to do the indexing.

Samuel: What would you say is the hardest part of database development? What is a major struggle?

Steven: I would say the struggles are not so much about the technology, but around the process. How do you build disciplined developers so they do the right thing and don’t just take a lot of shortcuts and – write code like me essentially (laughs)

As I mentioned before, I’m a popularizer, I wrote a couple of books, and people like what I write, they like the jokes that I put in the books, and they conclude that I must be some amazing PL/SQL developer.

Now, just because you write a good book doesn’t mean that you are a good developer. I think I’m okay at writing individual PL/SQL program units, and I can probably do it faster than anybody on the planet, but in terms of having the discipline to build an application correctly and carefully – nah, I’m terrible at that. I keep making the same mistakes over and over again for the last couple of years and probably will until I retire.

So to me, there’s not much of a technical barrier to the PL/SQL programming language – it’s a very straightforward language. It’s mostly around the process and the discipline that’s necessary to build applications in which we have a challenge. And that might be partly because we, the database developers, are not as much following the practices that are more common in other development environments, like using git for version control. But I don’t know – JavaScript developers might have the same struggles. That said: The simplicity and readability of database code on the other hand might make it harder to screw up than in JavaScript, but it’s still possible.

Samuel: Yeah I agree – also the strictness, especially of PL/SQL.

Steven: Oracle has always been pretty paternalistic about what you can do in its database. Sometimes we might not like it, but there are usually very good reasons.

Samuel: It wouldn’t be me interviewing you if I didn’t ask a question about utPLSQL. Two decades ago, you brought automated tests into the Oracle database. You even wrote a framework – utPLSQL version 1 and 2 – to help with that.

Why do you think automated tests on the database level still have so little acceptance?

Steven: Probably for the same reason they’re so little accepted across any other programming environment. I mean, do you really think that a higher percentage of JavaScript developers use automated regression tests?

Samuel: I think it depends a lot, but there are certainly programming language communities that embrace automated tests a lot more. Take python with its dedicated “test” keyword for example, or Java with a strong acceptance of JUnit automated tests.

From my perspective, the acceptance among the database development community is exceptionally low.

Steven: I will just say for the record, that I believe, that if we can find out the real percentage among the gazillions of Java developers who use and embrace automated tests, chances are this percentage will not differ so much from PL/SQL developers. That would be my guess.

But putting that aside for a moment, there are some specific challenges around database code testing. Famously, the idea of unit-testing is that you take an individual unit of code which is independent and just test it, because it is deterministic. These are the easiest things to test. But as soon as you have database dependency, all sorts of additional challenges come into play. So probably the biggest reason is, that the barrier to do automated tests in the database is usually a lot higher. And the barrier to do automated tests, in general, is high already because it takes time, it takes knowledge, and it takes management enlightenment to some extent to give developers the time and tools to do it. And this is even compounded by the additional challenges of databases.

Another reason might be that the database community is one that’s been around longer than … maybe not longer than automated testing, but certainly longer than things like Test-Driven-Development, Extreme Programming and other trends of the “agile movement”.

Samuel: So it also might be a cultural problem?

Steven: Yes, I think so. I mean – I noticed JUnit when it came out and thought it would be cool to have that for PL/SQL. But I never practiced it consistently and really used it in my development process and will probably not do it in the future.

I still don’t believe that our communities are all that different.

You got the additional challenges of databases. And you got the additional challenges of the database side of the stack being not respected as much, not getting as much attention, which means you lack the tools that exist for other parts of the stack. It also means that you don’t get as much money and resources to do good testing.

_ Samuel: Let’s close with a couple of questions that are not about PL/SQL. What is one of the best pieces of advice that you’ve gotten in your career? _

Steven: Normalize! I think that one of the reasons I like relational databases so much is that the idea of normalizing data to avoid redundancy (and more) synchs very powerfully with some internal drivers I have, namely around not wasting time or resources.

Don’t just normalize data, normalize code! Avoid redundancy in code, make the structure of your code clean and easy to manage. So for me one of the most powerful pieces of advice that I follow is to modularize: keep program units small, don’t get lost in a huge bunch of spaghetti code. That’s one of the principles I try to live by as I write my code.

Samuel: What would be one thing you’d say to someone who just started their journey into software development?

Steven: Put down your computer and go outside. More than that, put down your computer and BE outside.

Samuel: That’s a great one!

Steven: I’d say the most important piece of advice I’d give to any human being alive today, especially to anybody that lives in the technological, “modern”, “civilized” world, is: Stop hiding from your planet.

And I say that not only because the only way we can possibly destroy so much of our planet is by not being witness to it, by being disassociated from it as much as we are, but also because when we’re going out to our planet, we’ll be able to think more clearly, we’ll be able to solve problems more effectively, we’ll be healthier, we’ll be more comfortable in our own body. And all those things will make you a better developer.

It is really striking, Sam, to think about how many humans, and we’re talking about mainly middle-class people in a country like the United States, have almost no direct contact with planet earth. We live in our boxes. We wake up inside our box (home). We walk on our sidewalks to our car-box. We drive on streets that take us to our office box. And there is one very common feature of all these boxes: they have almost nothing alive in them. Except us and some plants.

You walk down a street in your city and if you’re lucky there’s a tree you walk by, which is really just a tiny gap in the sidewalk concrete that allows a trunk to come up.

For me, we are so far off any sort of rational and positive way to live on this planet, that the very first thing we need to do is reconnect to and with it.

Samuel: Time for one last question: If you weren’t a software developer – what would you be, work as, or focus your energy on full-time?

Steven: I think the number one thing any human being alive should be doing today is work on healing our planet. So I would do the same as I do now with all the time I’m not spending in front of a computer. What I do is I spend as much time as possible outdoors, fighting invasive species and helping our native ecosystems to thrive.

To me, the most important principle to follow is direct and positive action.

You can vote, you can donate, you can sign petitions, but what really is important is that you are going out into the world and making a difference in healing our planet and saving the lives of non-humans. And bring your children along!

Samuel: That’s a wonderful closing answer. Thank you so much for this conversation.

The post “Stop Hiding From Your Planet” – Interview with Steven Feuerstein about Databases, PL/SQL, and Direct Positive Action appeared first on Developer Sam.