October 2009 Archives
Over the past several weeks, I've had the obligatory parental experience of teaching a teenager to drive. This can be a nerve-wracking process as the new driver learns the mechanics of controlling the car: steering, using the pedals, shifting gears, checking rear-view mirrors, etc. But all these are relatively simple tasks that young drivers mostly master without serious problems.
The real harrowing experiences start only after new drivers have been driving for a while, when they're out on the road with other drivers. And that's where "learning to drive" truly comes into play, because it's not control of the vehicle that makes a good driver although that's certainly a prerequisite. Instead, it's the ability to anticipate the unexpected that makes a good driver--and unfortunately, that's a skill you can't teach.
You can talk about potential problems. You can describe them, and have the learner tell you what they would do in such situations. You can even practice avoidance maneuvers. But each new driver must personally experience many of the common driving hazards (and survive them) to be able to anticipate similar situations and take steps to avoid problems.
Sadly, the same rules apply to becoming a good programmer. Consider an application that stores some data in a file, retrieving it each time a user launches the application. Beginning developers, having learned the syntax to open and write data to files, simply write the few lines of code that read and store the data. If they've been programming a while, they might even write a test to make sure the code is reading and writing the data correctly. And because the code works, beginners think they're done; they've accomplished the task, met the specifications, and tested their work.
An expert programmer, faced with the same situation, knows it's not that simple. Sure, it's easy to write code to read or store some data in a file--when everything goes right. But it's not so easy to code the application to handle all the things that can go wrong, even with this simple operation. The file might not exist. The disk might be full. The file may be corrupted. The user may not have permission to access the file. The file might be in use. If the file's not local, it might not be reachable.
Granted, not all these problems are likely to happen at any given time, but developers who have delivered applications to large numbers of people know that, given enough time, all of them will happen, sooner or later.
An expert can tell a non-expert to check for such conditions, and with those specifications, the non-expert can probably code them, but only the expert anticipates them. Just like driving, what makes a good programmer is not only the ability to solve the problems that occur, but the ability to foresee (and avoid) problems that haven't occurred yet. Unfortunately, experts learn how to do that by making mistakes. It's a sad commentary on the human condition. Each generation acquires expertise primarily by repeating the mistakes of the past generations. To paraphrase Neils Bohr, "An expert is someone who has made all the possible mistakes in a very narrow field."
But when you're riding in a car with a novice driver, you'll probably appreciate P. J. Plauger's version more, "My definition of an expert in any field is a person who knows enough about what's really going on to be scared."
But we know that already. The really interesting part of McNealy and Gosling's exchange came at the end, when McNealy voiced his doubts that the Moscone Center where the conference is being held was big enough to hold OpenWorld and JavaOne simultaneously. Some in the Java community have speculated that the 2009 JavaOne Conference this past June would be the last. The rumors have Oracle killing the show and holding some scaled down version of it during OpenWorld. What would that look like?
The largest convention center in downtown San Francisco has three halls, Moscone North, South, and West. Oracle needs all three, plus rooms at an off-site Hilton, to accommodate the 40,000+ attendees. Not to mention that Oracle blocks off the street between the facing Moscone North and South halls, lays carpet down on the street, and erects tents above it (129,000 square feet of tenting, that is). It's a huge production. How Oracle would host another 15,000 people (the reported attendance at JavaOne 2009) is a logistical challenge I'm glad I don't have to face.
There probably wouldn't be much overlap in attendees who go to both shows either. Fundamentally, the conferences speak to different audiences: OpenWorld is an enterprise IT show for executives, while JavaOne is a developer show for Java programmers. Just observing the unwritten dress code at each one makes the difference obvious. Casual attire at OpenWorld is khakis and a button-down shirt with your company's logo embroidered on the breast pocket. That same outfit at JavaOne would be formal (What's with the khakis?).
Beyond the issues of sufficient space and differing styles is that of content. OpenWorld actually already offers content for Java developers. Oracle Develop is OpenWorld's three-day program dedicated to developer topics, and it held a number Sun-hosted sessions that were JavaOne-esque, including overviews and updates of JPA 2.0, EJB 3.1, Java SE, Java EE 6 and GlassFish, JavaServer Faces 2.0, and JavaFX. However, Sun is hosting only 10 out of a total of 217 Oracle Develop sessions--a fraction of the content JavaOne offers. Oracle would need to scale the number of sessions up significantly and find the room to host them.
Where Oracle Develop takes place also speaks volumes about the focus of OpenWorld. To get to Oracle Develop from the main show, you have to walk to a hotel about 10-15 minutes away. Shuffling off to the Hilton felt a little like being invited to a fancy dinner party and then been relegated to a wobbly ironing board in the den for your meal while the "grown-ups" (the IT executives) eat at the dining room table.
For Java developers, that feeling of being second-class citizens would be an unavoidable consequence if the shows merged. As the steward of Java, Sun constantly interacts with the Java community to help shape and plan JavaOne. During Goslings conversation with McNealy at the opening keynote, he confessed that Oracle was "a little unprepared for the volume of the Java community." Sun's developer programs, according to Gosling, are much larger in terms of downloads and interactions than those Oracle currently offers.
The developers who are downloading bits from the many java.sun.com projects, reading Sun distinguished engineer blogs, reporting bugs, and otherwise getting involved in the development of the Java platform make for an enthusiastic audience when Sun puts on a show just for them. (You won't hear the Brazilian contingent whoop and holler every time their country's mentioned here at OpenWorld, but you can count on it at JavaOne--and more than one keynote presenter has when his presentation starts to lose some steam.)
A backlash from developers who fear being marginalized in a merged OpenWorld/JavaOne likely won't be enough to save JavaOne if Oracle decides to end it; OpenWorld has swolled other conferences (PeopleSoft Connect and BEAWorld are just two). However, the audiences for the other shows it consumed have been more aligned with the IT executives who attend OpenWorld. With the logistical challenges and divergent audience, OpenWorld might choke if it tries to swallow JavaOne.
