NullPointerFactory

Back from day 1 of the conference. Here’s the raw, unedited, and uncensored rant.

First the good: all the speakers I heard today were very strong. This is not to say that I agree with all of them on all counts (more on this in a bit), but rather that their delivery was effective, and their material - enlightening and/or thought-provoking. Jared Richardson’s talk titled “Build Teams, not Products,” in particular, was one of the best presentations I’ve ever witnessed. It was just one of those talks where all the points seem tautological and obvious, until you consider how many (or rather, how few) you apply to your own work. I couldn’t come close to doing the talk justice by summarizing it here - if you can, hear it for yourself.

Another striking highlight was the manner and style of Neal Ford’s keynote. Very stirring, very effective. Mr. Ford clearly graduated the Steve Jobs school of presentations with the highest honors.

Ok, that’s enough ra-ra’s for one day. The time for complaining is nigh… Mr. Ford’s keynote, since we’re already on the subject, although excellently crafted and delivered, raises questions at best. Although entitled “Ancient Philosophers and Blowhard Jamborees“, the talk can be summarized in a sentence as “WebSphere and Rational ClearCase are causing our jobs to be outsourced to Chindia… permanently”. Our industry, as Mr. Ford, would have it, is crippled by the Svengali vendors of gargantuan and deleterious middleware, that renders us unable to compete with the likes of India and China. Really, Neal, WebSphere? Is WebSphere responsible for the 32% decline in the number of Comp. Sci majors in the U.S. from 2000 to 2004? Is WebSphere the reason why Bill Gates begged Congress to increase the number of work visas to the states? Or maybe SOAP is responsible for the war in Iraq? Perhaps CORBA brought about the current recession?

Don’t get me wrong - I’m no fan of WebSphere, and I loathe ClearCase with a burning passion (ask my manager!) Yet it seems obvious to me that there are far greater factors to explain our shrinking I.T. industry than its subservience to the mean, ugly middleware vendors. Is there vendor-induced inefficiency in I.T? Sure. But no argument in Neal’s keynote demonstrates that (A) this inefficiency does not exist in “Chindia”, and (B) when the “Chindian” companies start posing a threat to their American competitors due some gap in IT efficiency, that American business won’t rise to occasion. And for heaven’s sake, if you’re going to show a cruise ship to characterize a bloated piece of architecture, use the Freedom of the Seas, not the Carnival Conquest, which is lighter by about 40,000 tons and fits about 1500 fewer passengers. Hey, I’m a cruise ship fanatic, I couldn’t help myself.

The talk on meta-programming in Groovy with Jeff Brown was quite well done, but left one major unanswered question: all these closure delegates and meta-classes - if one is not building or using an internal DSL, what do they offer that a static language does not? The ability to stick a parameter into a method name instead of an argument? Don’t get me wrong - I really like Groovy, including the metaprogramming features. What angers me is seeing a couple of features that are useful within one specific domain (DSLs) touted as the death knell for Java, C# and the like… with a few compiler tricks and reflection/emission constructs, a static language could satisfy most meta-programming needs. C# 3.0 is well on the right path.

But just so I don’t end on a negative note, there’s one more thing that really impressed me today: the dessert selection at dinner featured these incredible soft brown pastries that I have so far seen in only three palces: Russia, Russian stores in the U.S., and on the M/S Noordam. Sampling them again today was a true pleasure.

To be continued…

It’s no secret that fewer Americans these days are going into math/science professions. Sure, we can blame, at least in part, off-shoring. But perhaps, and to a greater extent, we can blame the media-propagated “geek” imagery - the skinny, socially inadequate males who spend friday nights alone reading the code to the Linux kernel or something… Just for once I’d like to turn on the TV (if I had one) and see a computer geek shaped like Brad Pitt, or better yet - Angelina Jolie, shouting technobabble while riding the latest sports car with two highly appealing representatives of the opposite sex under each arm.

Instead, all we get is more of this:

I had this unpleasant situation a few days ago: a colleague, in process of making a fix, decided to rename some utility methods to better reflect their behavior. An admirable intention, but in the process, he had to modify around thirty different classes to reflect the naming change and broke every branch and local checkout that existed. He believes he did nothing wrong. I disagree. His mistake, as I consider it, is indicative of a tempting but fallacious notion of “our code” or “internal code”.

Look at it this way: If you were making a public API, say an XML parser, that was used by multiple third parties, would you make non-backward compatible changes to it and expect your users to accomodate? Would you rename public methods/fields/properties? Would you substantially alter their purpose or behavior?

Within just about any non-trivial code base, especially an object-oriented one, similar pieces of code soon emerge, even if they are not visible to third parties. Common data structures, utilities, even plain old beans that store configuration information - all of these things are examples of “Internal APIs”. An internal API is any piece of code that gets used in more than one nugget of functionality. Like their public counterparts, internal APIs require thorough design and dillidgent change management. If a member needs to be renamed, it is not enough to change the name - the deprecated name (clearly marked and documented as such) still has to be supported.

Changing behavior of members is tricker still… if a change introduces materially new behavior (rather than fixing bugs/quirks on existing behavior), the new behavior needs to come under a new name that clearly describes it… I would argue that even when all references to old behavior now merit the use of the new behavior, the new behavior needs to be a separate member unto itself - the act of updating all the code and tests that exercise the old behavior becomes the act of explicit confirmation that no assumptions of old behavior are present. Any invocation of an API member (internal or external) introduces coupling by assumption where the calling code makes an assumption of what the API call will provide. If the API behavior changes, the name has to change too, so that these old assumptions are forcibly and explicitly disclaimed.

Microsoft has announced it’s giving away Windows Server, Visual Studio, and a bunch of other development tools to all students for free. Big news, right? Naaaaahhhh. Guess what, Microsoft has been giving students software for free for ages. Except they didn’t call it “DreamSpark”, they called it “Piracy”. A student who wanted to learn visual studio, or play with the latest server OS could easily download it through a university’s broadband network or borrow a disk from a techie dormmate. But Microsoft & company never went after disk-swapping students with the bloodhungry zeal often observed with RIAA or MPAA… No… Microsoft counted on them. It always stood to benefit from a “get’em while they’re young approach”- if they get used to developing on and for Windows in school, they’ll seek out jobs that will utilize and expand these competencies. (more…)

Great talk from the 2007 JavaOne about how to program with the garbage collector in mind (free Sun Developer Network account required).

Some pertinent news, at least to me:

• Reference nulling is at best useless.
• GCs prefer short-lived, immutable objects. Young objects are cheaper to clean up than old objects.

There’s more juicy stuff in the presentation, but you’d be best off getting it from the source.