Reflections from RMOUG Training Days 2015 (part 1) - enough with the shoulds, already!?

I spent most of last week in Denver at RMOUG’s Training Days 2015. Some highlights and reflections follow.

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
  • PL/Scope
  • 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.


  1. I think you're on the right track in that asking people to change for no other reason than to become closer to the ideal programmer is going to set everyone up for failure.
    When I was learning to code, I really liked having a complete chunk of code that I could plug and play my stuff into. I'd love the time to totally understand what I'm doing, but I liked having a working solution first.
    If that didn't make sense, I like having working example code to plug my stuff into, so I could use the better methods before becoming a guru.
    Something that may be helpful is having a plsql 101: best practices in syntax and being nice to your server.

  2. Hello Steven,
    I think that the percent of those who like or can afford themselves the luxury
    "to deep dive" into each and every feature of a Language or tool just "for the sake of art" is rather low ... Most people are "common people", who have tasks to solve
    most often in a given and usually short enough time, and, once their problem
    appears to be solved, no one really cares "how perfect" or "how ideal" that solution was ...
    Except for very good reasons, mostly related to solving performance issues, and
    even out of those, solving the really very severe ones only, not many people will do recoding just for making the code "look nicer" or even "more easily manageable".

    That is, while there exists a chance to maybe refactor code for using FORALL
    ( not always a small issue, as we know from your last several Oracle magazine scenarios ), there is a very small chance for having someone refactor code
    just for implementing conditional compilation or making use of

    Another issue is that of ease of use.

    Though possibly useful, even very useful, features like profiling or PL/Scope
    are not easy enough to set up or to really comprehend and master, in comparison
    with their effective benefit, at least in terms of fast and immediate benefit.
    Especially since the advent of the visual tools like Toad, SQL Developer and all the others, people expect everything to be available immediately through a few clicks,
    and, since there are so many companies wanting to earn money, it is very likely
    that all these "complicated" features will be more and more incorporated into those tools and less and less used directly by developers, except for those who do work
    in developing such tools ... or ... well ... those who are PL/SQL Challenge-addicted
    and who will always be unsatisfied with their own knowledge level :( ...

    Thanks a lot & Best Regards,

  3. Hi Steven

    I've just attended your session on the Oracle Technology Summit. I love your delivery style. You give clarity to your message and an understanding of human nature to your training. Please keep doing what you do. It really does make a difference and some of us are listening even if it feels that we're not making use of your advice and expertise. Your input has made a huge impact on the work I do and I can't thank you enough.

    One thing Oracle could do is to make their training courses a lot cheaper so that developers don't have to wait for their employers to send them on a course. I'd definitely pay for more courses myself but can't afford a month's salary for a 4 or 5 day course. There's nothing quite like the physical classroom experience.

    Sending you much and genuine appreciation for the work you do. I'm now off to watch your vids, I know they will give me new knowledge but also a renewed enthusiasm.



  4. Stella, you're making me blush. :-)

    Don't worry, I and we will keep on doing what we are doing. Just always exploring new ways to do things better.

    By the way, Stella, I and friends at Oracle University were struck by your comment of a 4-5 day course taking a month's salary. OU courses are not cheap, but we didn't think they were that bad.

  5. Hello Steven,

    It doesn't happen very often that I actually reply to an expert's post (for some reason, Tom seems like a very scary person to me ;) ). But I've decided to make an exception in this case, as I actually don't fully agree with your statement. Let me explain. I actually feel like you're making up excuses for the shortcomings or unwillingness of certain developers. But I can see why you've come to this conclusion. For the last 3 years I've been fighting the same fight you have at my current employer. Step by step I’ve tried to improve the general quality of PL/SQL coding in my team. And to a certain degree I may have succeeded. Now, before I might come over as being arrogant or all-knowing, let me start by saying I'm definitely not some guru the way you or Tom are, far from it even. But I'm convinced that every developer should be able to follow some actually quite simple basic rules. One of my conclusions was also that you cannot force people in to this, you have to convince them of the usefulness. As such, together with the rest of the team we set up coding principles, syntax rules etc... we organized review and demo sessions, we developed new libraries and modules to make it easier. But still, after 3 years I still have very mixed feelings about the result. I was happy to see that some people were quickly picking up or at least seeing the benefit of it. But others, not rarely more veteran developers were very opposed to a lot of changes. It bothered me, as those were the same people that helped setup the coding principles in the first place. But when it came down to it, they didn't follow their own rules. How do you expect somebody new to follow them in that case? Lead by example and all that, you know. Now, I'm not somebody who easily quits and some might even describe me as a maniac to whom an additional space or uppercase matter. I'm guilty, I admit. But I noticed when confronted with the question why they didn't follow those basic rules we had setup together, they actually could not give me a decent reason or explanation. The most common excuses were "because I don't have enough time", which quite honestly is BS. Writing decent, readable code barely takes more time, especially once you get used to it, and in the long time it will save you (and your colleagues) a lot of time. Another classic response was "because that's the way we've done it for the last 20 years". I think if this is your answer, IT development might not be the right job for you. Some were actually honest and simply admitted they didn't, out of habit. And I honestly think in most cases that's the keyword: habit! Every change is difficult and following rules demands a certain discipline.

  6. ...continued...
    Another factor that seemed to play an important part into the process was the actual passion of the developer. Improving your code or at least your coding should be a continuous goal. And no, I'm really not somebody who spends hours and hours reading Oracle related books and articles about new features and I actually prefer spending my free time on no-Oracle related subjects. But I try to pick up little bits left and right, in a course, from other colleagues, through pieces of code I encounter, through Oracle Magazine, by reading a blog every now and then. When it seems useful, I then try to implement it. I myself also need to feel a certain pride over my code. If my own code is badly written or contains serious problems, I take it personally and won't be happy with it. I also feel a certain satisfaction over improving my coding. When I learnt about DBMS_UTILITY.FORMAT_ERROR_BACKTRACE (as it came up as an example) a couple of years ago I immediately saw the huge potential and implemented it in our existing error handling framework. All I had to do was add an extra column to the error log table(s) and call the function in my existing code. It has saved me hours, if not days solving problems later on. And being at it, I also replaced the classic SQLERRM by DBMS_UTILITY.FORMAT_ERROR_STACK. ? Now, I admit there remains one problem that is very hard to work around. You usually have to take over existing code and cannot always simply rewrite everything from scratch. I would love to, but that's simply not an option and it would probably take us years to do so. But that shouldn't keep you from applying your new rules and knowledge to new modules and code. And even with existing modules, I try to make little changes whenever possible. When for example I see the same query or statement 3 times in the same code block, it really doesn't take that long to replace it by 3 calls to a new package function or procedure. Those are small changes, but bit by bit they will improve the overall code. And if all developers in your team follow that logic and apply the established rules and practices to new pieces of code, the overall result can only get better. Note that most of these basic rules, be it readability, code reusage, the usage of packages (God, I hate loose functions and procedures!), decent exception handling, usage of privates etc... not only apply to PL/SQL, but to about every programming language.

    Just wanted to give you my 2 cents and take this opportunity to thank you for all your hard work and passion. I particularly love how you manage to explain often difficult topics or subjects in a very understandable and easy (and even fun) to read way. Keep up the good work and I'll continue trying to convince (or whine as you named it) people to put it to use.

    Kind regards,


  7. Erwin, thanks for sharing your experiences and views. I agree that it is largely up to the individual developer to take pride and sense of ownership in their code. But I also think there is so much more "we" (Oracle and also the community of expert users) can do to make it easier for developers to be aware of and then apply correctly the many features available to them.


Post a Comment

Popular posts from this blog

Table Functions, Part 1: Introduction and Exploration

Get rid of mutating table trigger errors with the compound trigger

Quick Guide to User-Defined Types in Oracle PL/SQL