The presentation had proved to be one of the hardest I have given, both in shaping the material and then in getting it down to 45 minutes. I went through it seven or eight times and it always took an hour. It was like a cartoon parcel: every time I pressed down on one bit another bit ballooned out. In the end I found myself in the hall just dropping whole chunks and hoping. I got to the wire with two minutes spare for questions (better than some other speakers I've seen this year).
My key insight into coding standards is that they don't make us better programmers. A program can be the acme of applied coding standards and still be functionally incorrect and bug ridden (although unit testing and code reviews should make that unlikely). More obviously a program can correctly implement the requirements and be bug-free yet fail to meet any set of coding standards whatsoever. No, the point of coding standards is to make us better team players, so that our programs play nice with programs written by other people. It's all about maintainability.
There was no time to relax after I finished because I had another session almost immediately. This session was difficult for another reason. I'd proposed the title Designing PL/SQL with a view to doing something different, something interactive, a sort of workshop. I'd prepared some design exercises with a view to stimulating some thinking. In hindsight I hadn't given enough thought to how I was actually going to run the session. In particular I hadn't got an ending, so it just fizzled out. It would have been a lot easier to give the session a shape if I could have topped and tailed it with some slides. But I chose to use the round table area so that people could talk and work together but it has no AV facility. So no Powerpoint. Also the exercises were too hard for people who had no experience in the sort of design decisions I wanted to explore, which seemed to be almost the whole audience.
So I await the feedback with interest. I don't know whether anybody else learned anything. But I certainly got some lessons in running interactive sessions. They are much harder than they look, because you need to put in just as much thought and preparation as a regular guy-plus-slides session, but rehearsing them is a trickier proposition (it's not really the sort of think you can do in a hotel room on your own). Still, the people in the UKOUG back office were supportive of the experiment, so I think I might have a second attempt at something like this next year. In the meantime, there are no slides to download for this session (obviously) but I will try to blog the exercises later.
After that session a couple of people asked me about automated unit testing, so I spent some time discussing testing in general and utplslql in particular. It made a change from evangelising to the uninterested, which is the more usual case. So I missed the start of Robyn Sands's talk on Root Cause Analysis in the service of reducing a support DBA's workload. She discussed the Five Whys as a technique for discovering what problem underlies an error message, the Ishikawa diagram for analysing all the possible sources of error and Pareto charts for seeing where most of the pain is. I particularly liked the way she redrew the Ishikawa fish to reflect a database scenario rather than its manufacturing origins.
The object is to fix the issues which will reduce the greatest number of calls, rather than reacting to the immediate symptoms. We all know thinking is good, but it can be hard to resist the pressure to resolve the surface issue and move on to the next ticket. Robyn was discussing a project she worked on which was dedicated to just eradicating persistent deep sources of bugs. The fact that this was a special project shows how hard it can be to resolve things properly in the real world.
My final task of the conference was chairing my colleague Roel Hartman's presentation on ApEx. This discussed a project to convert an archaic existing application (written in an obscure metadata-driven tool) into ApEx. The converted application had some neat features, including a good-looking planning tool with drag'n'drop. My concern is that Roel's presentation featured lots of JavaScript. How long can ApEx maintain a reputation for productivity when we still have to resort to bespoke coding for features as mundane as user-friendly calendar widgets and multi-column LOVs?
The contrast with Duncan Mills's session on the Fusion development platform earlier in the week is instructive. Duncan was discussing how the Fusion Apps developers are using JDeveloper. They operate under two rules:
- Write no SQL
- Write no JavaScript
No comments:
Post a Comment