July 2003

Every month, we receive letters from readers thanking us for our coverage of the design-build-test-deploy lifecycle for successful software projects. One of the must-read resources we provide is an annual developer salary survey. Our data is the most trusted and unique tool for anyone—from developer to project manager to chief technology officer—wondering whether they're getting paid what they are worth in the field.

If you work in the U.S., I'd like to invite you to participate in Software Development magazine's annual salary survey. The 26-question survey takes about eight minutes to complete, and can be found at http://www.cicresearch.com/Proj03792.

Please be assured that all responses are completely confidential. This is used exclusively as editorial research for an article to be published in the November 2003 issue. Only aggregate results will be used, and we will not disclose or use your e-mail address for any other purpose than to alert you to next year's survey.

Sincerely,

Alexandra Weber Morales
Editor in Chief
Software Development
CMP Media LLC
600 Harrison Street
San Francisco, California 94107 USA
[email protected]

A few years ago, I volunteered to re-engineer a Microsoft Access front end. I was eager to get my first really big mission, but I soon realized that I would rather have signed a lifelong contract with the Foreign Legion. The day came when, while scrambling through the vast tangles of spaghetti code that so conveniently hide almost anywhere in Access, I discovered the three lines of code that changed my life as a programmer (or at least changed the way I view other programmers):

Forms!frmMain!txtValue.Enabled = False
Me.txtValue.Locked = True
Forms("frmMain").txtValue.Value = ""

Each line touches the same object in the same form, but is written completely differently. Why would any reasonable person do this? I've been haunted for years by this question, and have come up with three possible explanations for this bit of early extreme programming (extremely bad programming, that is):

The conspiracy theory. Concerned about the Echelon worldwide spying system, the programmer wanted to obfuscate his intentions as much as possible. Indeed, no linguistic system could decipher this code, which looks and smells like Visual Basic, but uses the language in such an obscure way that it makes no sense at all.
The archeological theory. Just as the seas that existed and vanished millions of years ago left layers of limestone and fossils, different programmers modified this procedure, each adding a layer of code—because they clearly could not understand the previous stratum.
The schizophrenia theory. The programmer was suffering from advanced multiple personality disorder. As you can see, the personality switch was very fast: the first line written by Dr. Jekyll, the second one by Mr. Hyde, and the third—well, the third was by Mr. Anderson (who obviously took the wrong pill this time).

I'll let you choose the most appropriate answer. Someone less ingenuous than me might simply call this sabotage.

—David Dossot, Software Engineer and Architect
Thionville, France

This piece was originally published in the October 2002 issue. Do you have a deployment or beta horror story that you're dying to tell? Send your tale of no more than 500 words to [email protected] for possible publication in the October 2003 issue. Submission deadline is July 15, 2003.

Sun admits Java has lost ground to .NET, blames marketing.

Sun Microsystems CEO and founder Scott McNealy has the rakish charm and plainspoken humor Americans enjoy in their presidents, be they elected or corporate. He's also got a few extras, starting with a Stanford education and concomitant passion for excellence, both of which make the McNealy keynote at JavaOne in San Francisco's Moscone Center a high point of the company's annual conference. The eighth annual event, in June 2003, was no different. The usual flashy apps took the stage, among them Motorola's digital personal companion, an all-in-one handheld computer, two-way radio, interactive pager and the first wireless phone in North America to incorporate Java 2 Platform, Micro Edition (J2ME).

Then there was the gloves-off assessment of the ongoing battle with Redmond. But a new contender entered the ring this year: the media. To this reporter, mentions of newspaper and trade coverage of Sun seemed more frequent and biting than in years past, culminating in a tirade about a San Jose Mercury News reporter's article that indulged in the fashionable speculation about whether Sun was an acquisition target for any of its competitors. "I'm going to not vote for anything but an all-cash offer," he joked. "And there aren't too many nonconvicted monopolists with $17.4 billion in spare change."

McNealy made no secret of Sun's lackluster performance in the software market, but he attributed it primarily to feeble marketing efforts that were crushed by the Microsoft .NET juggernaut in the last year. In a humorous bit that presented Java with a report card on such subjects as class participation, choice and branding, he awarded his company an F in marketing. On the other hand, he bragged about Java's security model: "Unlike some people, I didn't have to issue a memo to tell my employees that security was important," he said, referring to the January 2002 Bill Gates directive on "trustworthy computing."

But, in its ongoing competition with Redmond, Sun's biggest gamble is that of eschewing the desktop. "Plastic-wrapped, metal-wrapped, rack-wrapped and gift-wrapped software distribution models are rapidly replacing the standard shrink-wrapped model, changing the very essence of the software industry," McNealy claimed. "Consumers more and more will demand Java-based mobile devices like phones and PDAs—essentially ending the consumer era of software sold separately."

—Alexandra Weber Morales

The average consumer probably isn't aware that Java is everywhere, nor does she care. Sun is aiming to change this: At the JavaOne conference, Executive Vice President Jonathan Schwartz announced an aggressive, multimillion-dollar "Java Everywhere" campaign to heighten consumer awareness with a new logo—a steaming cup of coffee, of course. The goal? To remind users that Java is under the hood and drive them to not only buy, but demand Java-enabled devices. Sun is asking manufacturers to place the Java logo on their products, just as the Intel Inside campaign did on PCs.

Schwartz's cited statistics on Java's ubiquity were impressive: Java's in all the Fortune 500 companies, 24 million SDKs have been downloaded, it lives on half a billion desktops, 22 manufacturers use it, nearly 100 million Java-enabled phones are in the field, and 53 carriers are deploying Java services. Another Sun initiative aims to simplify the Java stack much the way the .NET concept has done for Microsoft: Schwartz proposed one community, one Java (combining JavaCard, J2ME, J2SE and J2EE), one platform, a common architecture and one network for interoperability. Over the past five years, Sun has faced more challenges than ever: The complexity and multitude of Java platforms and products are enough to confuse any developer, and many are flocking to Microsoft's .NET. Michael Bouchard, a senior architect with the consulting firm CapTech, agrees: "The different Java platforms confuse issues; clients don't understand them."

While Schwartz stated that the success of Java depended on the simplification and integration of technologies to one new platform, he didn't offer how it would be realized or a timeframe.

Meanwhile, Toronto-based Tira Wireless was ecstatic. "I would love to see people asking for Java and saying 'I have a Java phone,'" said Wayne Seifried, director of product marketing. "It significantly extends our marketing dollars and reach." But smaller companies such as aJile, which offers a unique hardware Java processor, says it's just another Sun marketing ploy to pull in more cash from their partners. "We've had no help from Sun to get our product to market, and we've had to pay substantial licensing fees—this [branding] is just another way for them to make more money," said Application Manager Thanh Nguyen. The consumer doesn't care what language an application is written in, Nguyen believes—only in its quality.

Developer Michael Yuan voiced yet another concern from the open-source community: "It's quite obvious that Sun is determined to ensure maximum compatibility for any product with the Java logo. Compatibility means that all vendors must stick strictly to the official specifications created by the Java Community Process. While all vendors are invited to participate in the JCP, this 'specification first' development paradigm does create friction with the open-source community. In the world of open source, people develop products that address immediate needs and then expand them with additional features. Specifications become necessary only when multiple projects start to fragment the market—developers rarely find it fun or cool to build to an arbitrary and complex specification developed by a committee. How to reconcile the JCP with the open-source development paradigm is a big issue facing the Java community today."

—Rosalyn Lum

Code Camps come to the conference.

"Turnout was fabulous—it was as good as we hoped it would be," said Frank Curran, a manager of the Technical Evangelist Group about the popularity of JavaOne's inaugural Hands-On Sessions, helping developers adapt to emerging technologies. Three day-long programs were offered in J2EE, Java Web Services and Mobile Computing, giving developers new to programming in these environments a walk through the process.

Although new to JavaOne, the concept of hands-on programming has been a Sun signature for years and, Curran boasts, has had a direct impact on sales. Smaller-scale Code Camps packed with technical content, programming exercises and sample code are conducted throughout the world for ISVs, generally tailored for classes of no more than 20 participants. "The feedback has been tremendous," Curran gushed, "and we're ready to roll the program out on a larger scale."

At JavaOne, participants had to preregister for the Hands-On classes that met throughout the day. The four-hour program was divided into three parts, kicking off with an hour-long technical presentation/tutorial for all registrants. Participants were then split into three groups, each attending a two-hour programming lab, and manuals guided them through the program. A one-hour evening birds-of-a-feather discussion wrapped up the day.

All skill levels were present—some programmers were not as strong as others, and a few of them left frustrated; others felt that they could have gone faster and packed more into the lab without the tyros dragging them down. To remedy this, Curran offered that future sessions may include beginner, intermediate and advanced programmer tracks.

—Rosalyn Lum

How to tell the truth about your system with statistics.

Just as test-driven development embeds testing in the programming process rather than as a separate function, Sun evangelists Tom Marble, Senior Java Performance Engineer; Timothy Cramer, Java Performance Engineer; and Menasse Zaudou, Java Performance Engineer, expounded on the virtues of tying micro-benchmarking to the project plan and product development cycle. In their JavaOne session, they explained that though benchmarking success is still a what-you-make-of-it approach, developers can make results more meaningful and less of a black art.

Micro-benchmarking is the measurement of a large number of parameters in localized areas to guide thoughtful design. "They are generally easy-to-understand, much abused by marketing and used for high-level decisions. Best of all, they ensure that you don't get fired," says Cramer. For example, micro-benchmarks can be used to tune applications, the Java virtual machine and the operating system, or to sniff out hardware conflicts. Benchmarks can also be used for non-invasive monitoring of real product behavior.

Want to write meaningful micro-benchmarks that are more than just marketing fodder? First off, the speakers recommend, know what your measures are really measuring. Understand the number of observations and what the variability means—and if you're not clear on those statistical terms, you may wish to pick up a refresher textbook. It's also crucial to collect enough data from various platforms and systems for a representative sample. When evaluating multiple measures (threads, memory, IO and so on), change only one variable at a time. Visualize your results with scatter graphs, plots or a chessboard. Create profiles and monitor them to better visualize changes over time. Be consistent and keep raw logs. Most importantly, link your benchmarks to the project plan. Ignore these guidelines, the speakers warn, and your numbers will continue to have no more credibility than a deck of Tarot cards.

—Rosalyn Lum