Love Those Two Hour Deep Dives
I signed up to do a two-hour deep dive on error management features in PL/SQL. Wow, that was great. Great as in: it’s hard for me to cover much of anything in just one hour (and even more challenging at OOW, in which sessions are now 45 minutes!). Whatever my strengths, brevity is not one of them.
So having two hours to explore a constrained set of PL/SQL features amde it more of, well, an exploration instead of a mad dash I hope the attendees felt that way, too. I still ran out of time, but I’d like to think that at least attendees could absorb a little bit more of what I presented.
Thinking about Utilization
That same deep dive got me thinking once again about the relatively low level of utilization of non-basic features of the PL/SQL. For example, of the 100 or so Oracle techies in attendance, when I asked how many were using DBMS_UTILITY.FORMAT_ERROR_BACKTRACE, no more than 10 hands were raised. Now, it is certainly possible that people just don’t like to raise their hands, but it seems more likely that this is just one more feature (added in 10.2) among many that developers have not integrated into their standard toolkit.
And the list of valuable but largely neglected features goes on and on….
- Compile time warnings
- Conditional compilation
- Collections, especially nested tables
- MULTISET operators
- Profilers (DBMS_HPROF and DBMS_PROFILER)
And then there is the issue of best practices. Tom Kyte, Bryn Llewellyn and I have whined (that’s how I tend see it now, explained more below) for decades (!) about how developers should do this or do that, as in:
- Don’t swallow up errors with WHEN OTHERS THEN NULL
- Hide your SQL statements behind a PL/SQL API
- Unit test your code
- Avoid row by row processing
And yet (again, from a very unscientific feeling about your world, based on admittedly lmiited datasets), many developers just keep on doing the same old thing, unable to jump out of their well-worn ruts.
Why? What’s wrong with these developers?
Wait a minute - did I really say that? Do I really think there is something “wrong” with the hundreds of thousands of developers who don’t follow best practices, who don’t utilize non-basic features, old and new?
No, I do not. In fact, I think there is something wrong with me, with Tom, with Bryn (all right, fine, I won’t make any claims about Tom and Bryn. There’s something wrong with me). We keep expecting all of you to change the way you do your work. We expect that you, in other words, will change to meet our construction of the ideal PL/SQL progammer.
And if we lived in an ideal world, this expectation might not be quite so futile.
But in the real world, you face enormous pressure to produce code quickly. Many dev managers are not willing to or cannot give you the time needed to learn about new features, play around with them, integrate them into your daily workflow.
In this world, our constant refrain of “Do this, do that, c’mon people!” might not really be doing all that much good, and could even generate some bad feelings that make it hard for developers with the best of intentions to change their habits.
So after many years of singing the same tune, I find myself thinking: we (the experts, the gurus, the fonts of wisdom) need to take a different approach.
Perhaps it is time to accept that most people simply will not change. Rather than lecturing people (whatever the form of the lecture: book, blog, video, etc.), maybe we should look at ways to make it much easier to use these features or be reminded of them.
And I don’t mean “just” doing that in our products, like SQL Developer and PL/SQL itself. I mean what can be offered to users outside of the product path (which, as you well know, means a long, slow path - in terms of development, testing, release and then uptake)? And what could be worked on not only or primarily by Oracle employees, but by expert users “out there”?
I have one idea, which I will publish in a separate post. But I would love to hear if any of you have ideas along these lines or if you think I am off base in my conclusions.