tag:blogger.com,1999:blog-7849367040589270673.post7108163171940385870..comments2024-03-21T22:50:39.997-07:00Comments on Obsessed with Oracle PL/SQL: Reflections from RMOUG Training Days 2015 (part 1) - enough with the shoulds, already!?Steven Feuersteinhttp://www.blogger.com/profile/18405765731886460622noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-7849367040589270673.post-53469757784277135472015-03-26T08:36:15.990-07:002015-03-26T08:36:15.990-07:00Erwin, thanks for sharing your experiences and vie...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.Steven Feuersteinhttps://www.blogger.com/profile/18405765731886460622noreply@blogger.comtag:blogger.com,1999:blog-7849367040589270673.post-15472387311282811382015-03-26T08:18:17.395-07:002015-03-26T08:18:17.395-07:00...continued...
Another factor that seemed to play......continued...<br />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.<br /><br />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.<br /><br />Kind regards,<br /><br />ErwinAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7849367040589270673.post-87746184175979015792015-03-26T08:18:02.874-07:002015-03-26T08:18:02.874-07:00Hello Steven,
It doesn't happen very often th...Hello Steven,<br /><br />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. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7849367040589270673.post-5581225555640648292015-02-28T05:48:56.262-08:002015-02-28T05:48:56.262-08:00Stella, you're making me blush. :-)
Don't...Stella, you're making me blush. :-)<br /><br />Don't worry, I and we will keep on doing what we are doing. Just always exploring new ways to do things better. <br /><br />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.Steven Feuersteinhttps://www.blogger.com/profile/18405765731886460622noreply@blogger.comtag:blogger.com,1999:blog-7849367040589270673.post-12742914352846939082015-02-25T05:53:38.416-08:002015-02-25T05:53:38.416-08:00Hi Steven
I've just attended your session on ...Hi Steven<br /><br />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. <br /><br />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.<br /><br />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.<br /><br />Cheers<br /><br />StellaStellanoreply@blogger.comtag:blogger.com,1999:blog-7849367040589270673.post-21164927450093135902015-02-24T10:57:59.632-08:002015-02-24T10:57:59.632-08:00Hello Steven,
I think that the percent of those wh...Hello Steven,<br />I think that the percent of those who like or can afford themselves the luxury <br />"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<br />most often in a given and usually short enough time, and, once their problem<br />appears to be solved, no one really cares "how perfect" or "how ideal" that solution was ...<br />Except for very good reasons, mostly related to solving performance issues, and<br />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".<br /><br />That is, while there exists a chance to maybe refactor code for using FORALL<br />( 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<br />just for implementing conditional compilation or making use of <br />DBMS_UTILITY.FORMAT_ERROR_BACKTRACE ...<br /><br />Another issue is that of ease of use.<br /><br />Though possibly useful, even very useful, features like profiling or PL/Scope<br />are not easy enough to set up or to really comprehend and master, in comparison<br />with their effective benefit, at least in terms of fast and immediate benefit.<br />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,<br />and, since there are so many companies wanting to earn money, it is very likely<br />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<br />in developing such tools ... or ... well ... those who are PL/SQL Challenge-addicted<br />and who will always be unsatisfied with their own knowledge level :( ...<br /><br />Thanks a lot & Best Regards,<br />Iudith<br />iudithhttps://www.blogger.com/profile/04905902445036068357noreply@blogger.comtag:blogger.com,1999:blog-7849367040589270673.post-64942992661092628562015-02-24T05:37:04.731-08:002015-02-24T05:37:04.731-08:00I think you're on the right track in that aski...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.<br />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.<br />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.<br />Something that may be helpful is having a plsql 101: best practices in syntax and being nice to your server.Anonymoushttps://www.blogger.com/profile/05300499467108007694noreply@blogger.com