04Mar
By: Steven Feuerstein On: March 4, 2021 In: Insum Life, Oracle APEX Comments: 2

Hi, my name is Steven Feuerstein and I do PL/SQL. 🙂

On February 1, 2021, I joined Insum Solutions as a Senior Advisor. My primary role, roughly speaking, is to help Insum improve the quality of the backend code that powers its many Oracle Application Express (APEX) solutions. I will also directly assist Insum customers when and where appropriate. My tasks will include:

  • One-on-one mentoring of Insum consultants
  • Mentoring/training of Insum customer developer
  • Group trainings on PL/SQL features and best practices
  • Improving code sharing and reuse among our developers
  • Feuertips: a new weekly PL/SQL tip series we will be announcing shortly

A Brief History of My PL/SQL Life

My specialty is the Oracle PL/SQL language. You might even call it my obsession. I first started using PL/SQL during my first stint at Oracle, from 1987 to 1992. I used it in SQL*Forms 3, the first place that PL/SQL appeared. That was an enormous improvement over the SQL*Forms 2.x trigger logic.

PL/SQL got really exciting, though, with version 7 of Oracle Database, when the PL/SQL dev team added full support for packages and other stored program units, exception handling, embedded (static) SQL, and so much more.

I left Oracle in 1992 and became a consultant. I’d always liked to write and when in 1994 publishers realized there was a large-enough market of Oracle Database developers, I took a chance and signed up to write a book called Oracle PL/SQL Programming for O’Reilly Media.

It was the first independent reference on PL/SQL (that is, not Oracle documentation) and it was a big hit, relatively speaking. It became popular enough to be called “the Bible for PL/SQL developers” and free me up from daily consulting, so I could devote myself fully to helping developers make the most of PL/SQL.

Which I did, first as a PL/SQL evangelist for Quest Software (and then Dell), up through 2014. Then I returned to Oracle Corporation to lead a team of Developer Advocates.

Along the way, I trained thousands of developers, wrote ten books on PL/SQL (yes, ten, about 6 too many, I figure looking back), countless articles and blog posts. I recorded hundreds of videos on the topic, visited dozens of countries to present at conferences. I’ve also picked up a few speaker awards, and was one of the first Oracle ACE Directors.

I also created a website called the PL/SQL Challenge that offered daily ranked quizzes on PL/SQL. At its peak we had over 2000 developers taking the quizzes each day. That website was transformed into the Oracle Dev Gym (https://devgym.oracle.com), which now offers quizzes, workouts and classes on SQL, PL/SQL, database design, logic and more. All free, of course.

Yet even the best job in the world can get, well, repetitive after awhile. There will always be more to say and write about PL/SQL, certainly. But after almost 7 years at Oracle (in my second round), I decided it was time for a change. I wanted to work more closely with developers who were doing the work (delivering solutions for customers with PL/SQL) and I wanted to help make Oracle Application Express (APEX) more successful.

APEX and I

Oracle Application Express in so many ways represents the best of Oracle – the best of Oracle as a company, the best of Oracle as a product, the best of Oracle as a demonstration of just how powerful database-driven application development is.

APEX as the best of Oracle as a company: really forever, but especially in the 21st century, developers are driven by values. Values like open, transparent, user-centric, community, productivity, elegance, performance. And from the start APEX and its awe-inspiring development team (led by Michael Hichwa and Joel Kallman), offered a product and a way of working with its users that was nothing less than best-in-class.

The development team has worked closely with – and FOR – its users from day 1. Bugs are fixed quickly, customers receive support not only through Oracle Support but directly from developers, often through (or triggered by) social media. This has resulted in a vibrant, devoted, and incredibly enthusiastic community.

But mostly the APEX team has come up with (and continues to enhance in ways big and small) a product that inhabits a sweet spot for developers: it does most of the heavy (and boring) lifting – generating Javascript, HTML, CSS and even SQL, allows you to accomplish an enormous amount with point-and-click, but it also makes it easy for developers to dive deep into coding as needed to produce the desired results.

Is APEX the only low-code tool out there? Of course not. Is it the most mature, with the largest active developer user base, and a devoted following among both developers and users? Absolutely!

What I like most about APEX, though, is very simple and visceral: it allows me, The Man Who Knows Only PL/SQL (and a smattering of SQL and HTML), the ability to build decent websites. Who woulda thunk it? 🙂

Watch What You Ask For

So, yes, APEX is very wonderful and literally hundreds of thousands of people are busy, as I write this, building applications with APEX. So productive! So quick and easy to create smart, data-driven websites!

But also so easy to dig oneself into a hole that can be hard to climb out of.

What do I mean by that? The danger of any point-and-click, low-code tool is that the shift to writing code becomes relatively infrequent and somewhat painful when it happens. We want to hurry up and write a query or a block of PL/SQL code, and then get back to making the application look wonderful and meet all user desires.

Also, many APEX applications start off as relatively small, departmental apps, but then grow in complexity, data volume, and users. If the database side of the application is given short shrift (because we have become convinced that APEX will “do it all” for us), then the very success of our applications can lead to serious challenges. Developers who can put together a decent APEX app are not necessarily the same developers who know how to write optimized SQL statements or easy-to-maintain PL/SQL packages.

I worry, now and then, that there will be a reckoning in the future for many early APEX success stories, if that moment arrives when suddenly a deeper expertise of Oracle Database is needed. It will be unfortunate if APEX is blamed for the problems with these applications. But, of course, it’s not a matter of blame, it’s a matter of recognizing the need to have a balanced set of expertise in any dev team (or in an individual if the dev team is very small, like one or two).

That’s where I intend to focus my efforts at Insum: strengthen the “behind the scenes” PL/SQL skills of our consultants, help ensure that as their customers’ demands grow, the apps we built for them scale right up and meet those demands.

Looking Into the Glass Ball

I believe that APEX is, in many ways, the future of Oracle Database; this low-code tool has been exploding in popularity, and I believe exponential growth lies ahead. And APEX will pull the database along with it. I believe that in the years to come, most of the PL/SQL code that will be written, will be written for (and in) APEX applications.

I am, therefore, very happy to join the Insum team for the next phase of my Oracle journey – in PL/SQL and APEX!

So if I want to continue to help developers make the most of PL/SQL, it is going to be in a more APEX-centric role. Which I now have at Insum Solutions, in the sense that almost all of their activity is centered on APEX.

Share this:
Share

2 Comments:

    • Monty Latiolais
    • March 05, 2021
    • Reply

    Welome aboard, my friend.

    • Dan Clamage
    • March 10, 2021
    • Reply

    I was thrilled for the opportunity to delve into APEX here at work 7 years ago. It may be “low code”, but having a strong background with PL/SQL and SQL really helps make your applications better. All of the same backend coding and design standards applicable to client-server and full-stack web development still apply to APEX. Enjoy your newest endeavor!

Leave reply:

Your email address will not be published.