After a circuitous route through Davis before it got here to Seattle, my copy of Java Developer's Journal finally showed up at my doorstep over the weekend, and from the top of the magazine's cover blared Calvin Austin's editorial entitled "C#: Is the Party Over?"

Huh?

As I read through the editorial, I began to realize that not only were the points ill-conceived, but that Mr. Austin doesn't even offer up credible or factual basis for his perspective--in other words, this is FUD at its best, the very same tactics that Sun accuses Microsoft of using when the facts don't suit.

Mr. Austin begins by justifying his expertise on the subject by saying,

One of my tasks at Sun was to keep abreast of the technologies in the marketplace that competed with Java.

Next, he begins his arguments as to C#'s iminent demise:

The .NET platform has been under constant development, often too fast for many corporate users to accept. There has been a 1.0, 1.1 and 2.0, each which could be counted as a significant version in their own right.

What I find fascinating, however, is the implicit criticism that innovation and progress is bad. Corporate users aren't accepting of too many changes, true--this is precisely the experience Sun faced during the 1.1.x hyper-release cycles, when they were castrated in the press for doing too many releases in too short a period of time. But an eighteen-month release cycle (which is the current development cycle for the .NET teams) is hardly what you call rapid, and frankly, I've heard a number of developers complain that the releases are too far apart to begin with. Coupled with the fact that both platforms support a very good side-by-side deployment story, I think both Sun and Microsoft could stand to shorten their cycles, not point-and-kvetch that the other side is releasing too quickly.

Next we see Mr. Austin point out that C# hasn't been the astounding success Microsoft wanted it to be:

Looking at the forums, Visual C++ and Visual Basic and not C# attract the lion's share of the forum attention.

In addition, the underground community site, gotdotnet.org, has undergone significant site and management changes.

The C#, C++ and C compilers are now free, although not obviously as optimized as the professional edition.

Mr. Austin continues with his analysis by pointing out that C# "didn't make the grade" because:

... the Java platform did not stand still. Many of the benefits that the Java platform delivered were not solved by moving to C#, the most significant difference being OS independence.

While C# was in rapid release mode, the Java platform was able to fine-tune the language and at the same time invest heavily in stability and scalability.

Deploying a .NET service leaves a company a small choice of application servers and OS versions.

The criticism continues with his prouncement that "open source changes everything":

While developers had to get budget approval for MSDN licenses, the Java colleagues were able to deploy a system for free.

The growth of open source Java hasn't stopped there. You only have to look at Hibernate, the Spring Framework, and Struts/Shale to see that developers can work together to solve their own problems.

And no Java-centric criticism of .NET is complete without bashing Mono for a bit:

Mono today is still a development project much as .NET is still looking for full traction.

Mr. Austin wraps up his editorial with:

Is the C# party over? If the plan of C# was the slow the defection of Visual C++ developers to Java, then it was certainly better than nothing. The long-term savings for Microsoft in sharing a CLR between projects was more than worth the initial effort. However, C# is still not the de facto choice for web site or enterprise development and other languages such as Python and PHP, which are bringing in a new generation of developers who don't have a need to migrate Visual C++ applications. C# isn't going anywhere soon but its best days may be behind it.

• Is the C# party over? Considering how he's been equating C# and .NET as one and the same thing, Mr. Austin clearly demonstrates his inability to tell the difference between languages and platforms, a failing of Sun's for the past decade. Even assuming C# as a language were to fall apart tomorrow (highly unlikely), the other languages--Visual C++, Visual Basic--would keep .NET alive for a very long time to come. So, if you're to refute my arguments, make sure you clearly delineate between refuting the language (C#) or the platform (.NET). Combine this with the fact that Microsoft is about to unveil the plans for C# version 3.0, it hardly seems logical to suggest C#'s party is over.
• If the plan of C# was to slow the defection of Visual C++ developers to Java... An interesting insight, one that I particularly agree with. But it also sells short the idea that Microsoft simply saw the union of Java-the-language and the platform (COM at the time) as a Good Thing, one that they wanted to enhance and adopt for themselves.
• ... then it was certainly better than nothing. Ah, a masterful choice of words, implying that there were much better things they could do, but chose not to for a variety of reasons. What those things were, who knows, particularly since Microsoft DID try to use Java as the core of their platform going forward (by leveraging Java and custom attributes, yielding J++) but were sued out of it by Sun.
• The long-term savings for Microsoft in sharing a CLR between projects was more than worth the initial effort. Don't be too quick to toss this off, Mr. Austin--the costs in sharing a platform between languages are subtle and deep. The cross-language .NET project is a lot more complicated than many people believe, and we can see that trying to build a platform that's somehow "universally acceptable" to all kinds of languages is a difficult thing by looking at the efforts under way on the Parrot project. Microsoft has certainly done a powerful thing in building the CLR--and standardizing it--but it wasn't easy, and something whose costs and effort hasn't been fully measured yet.
• However, C# is still not the de facto choice for web site or enterprise development... Not amongst the Java crowd, certainly, but there's a lot of sites out there with ".aspx" in their URLs--measure for yourself if you don't want to believe somebody else's statistics--seemingly putting the lie to Mr. Austin's cavalier statement.
• ... and other languages such as Python and PHP, which are bringing in a new generation of developers who don't have a need to migrate Visual C++ applications. Huh? This part of the sentence doesn't even make grammatical sense, but what I think he's saying is that a whole collection of website developers, who currently use Python and PHP, have no need or desire to adopt C#. Got news for ya, Mr. Austin, this is the same crowd that has no need for Java and J2EE either. They're hung up on Ruby and Rails right now, and probably still have a huge collection of Perl scripts that they use on a regular basis that have no easily-ported Java--or C#--equivalent. Fact is, the scripting crowd has very little use for any statically-typed, compiled language, be it C++, Java, or C#. Or VB, for that matter.

In the end, the reason I refute the meat of Mr. Austin's editorial is simple: Java developers are being fed a constant stream of FUD about the .NET platform these days, just as the .NET community is being fed its own set of FUD about the Java platform by various players there, too. I find myself spending about equal amounts of time explaining the Java community to the .NET world as I do explaining the .NET world to the Java community, and although I typically get nothing but ridicule, anger and/or disbelief from the various zealots on both sides, I find that the majority of developers I speak with on the subject are quite interested to hear what the "other side" is doing. It goes back to what I said earlier--the more you know about the other platform, the more you can leverage their experiences and innovations for your own use. But the first step to learning about the other platform is to recognize that they're doing something useful, and not just write off everything happening as irrelevant or meaningless, or to make such boldly unsustainable claims as "The Party's Over" or that "its best days are behind it". More importantly, it's editorially irresponsible that JDJ published this tripe; granted, JDJ's readership may think it wants to hear that the .NET platform isn't useful and powerful, but that's a factually incorrect statement and is likely to cause more pain in the long run than to simply face up to the fact that .NET is Java's twin brother and can do anything Java can do.

Jared Richardson took issue with my assertion that there's no such thing as best practices, stating that, in essence, it's not kosher for me to deny existence of something that I have to define:

They said "There are no best practices" and then they had to define the term... but they defined it wrong! A best practice isn't a required practice or a universally dominant practice. It's just one of the best ones. It's used quite often, but not everywhere and not always. (No such thing as best practices? Sure there are!)

Unfortunately, Jared, the semantics of the term "best practice" implies exactly that: something that's used everywhere and always, for when would anyone choose not to use a "best practice"? And if it's not used everywhere and always, then it's not "best", implying "better than all alternatives", ya?

How about, at the end of the day, we just drop the term "best practice" altogether, and stick with "useful practice" instead? Would that satisfy everyone's sensibilities?

A couple of people have asked me what my speaking schedule looks like for the next quarter, so, barring any last-minute cancellations or shifts in schedule, here's where I'm going to be over the next few months:

• Aug 27-28, Cincinnati, Ohio: Southern Ohio Software Symposium, doing my usual raft of $NFJS talks: "The Ten Fallacies of Enterprise Computing", "Effective Enterprise Java: Security", "Introduction to Web Services, 2005 edition", "Java Metadata", and an architecture/end-of-conference open forum
• Aug 31, Portland, Oregon: Portland Area DotNet User Group, doing a talk on .NET persistence options
• Sept 14-15, Oslo, Norway: JavaZone, doing talks on "Concrete Services" and "Effective Enterprise Java"
• Sept 16-18, Chicago, Illinois: Great Lakes Software Symposium, another $NFJS show
• Sept 20, South Bend, Indiana: Michiana Area DotNet User Group, doing "Intro to WS-2005"
• Sept 25-30, Arhus, Denmark: JAOO, doing "Passing Messages", "Core Indigo Patterns", "Effective Enterprise Java" and "C# Intro" (for Java developers who haven't picked up the CLR/.NET thing yet)
• Sept 26-29, Boston, Massachusetts: SD Best Practices (yes, I know this overlaps with JAOO; it's going to be a very interesting travel week for me that week ), speaking on "Passing Messages" and "The Fallacies of Enterprise Systems"
• Oct 11, Orlando, Florida: VSLive! Orlando, talking on "Hosting ASP.NET"
• Oct 14-16, Seattle, Washington (my new hometown!): Pacific Northwest Software Symposium, another $NFJS show
• Oct 28-30, Reston, Virginia: Northern Virginia Software Symposium, another $NFJS show
• Dec 5, Salt Lake City, Utah: Utah .NET User Group, talking about... er... something interesting (we haven't decided what yet)
• Dec 13-17, Belgium: Javapolis, though... I'm not sure what I'm speaking on, and I'm not on the wiki (yet?)

And it's entirely possible I've left something out, so if you think I'm speaking at an event near you and I don't have it listed up there... email me? Please?

Update: It looks like I won't be at the $NFJS Calgary show, despite my earlier having committed to it; the travel logistics required to get there are just horrendous. So no, I'm not doing NFJS Calgary, despite what it says there on the website.

If you're going to take the time to leave a comment, you obviously want your views to be heard, by either me or the people who read my blog, or both. So, then, take the time to make sure your views--and not just your opinions--are presented in the best light possible. Offer arguments, credible or otherwise. State your reasoning. Explain why your conclusions differ from mine. Don't just write "I don't agree" or something similar to that effect, because several things happen when you do this:

1. Basically there's nothing for me (or others) to learn from it, so I pretty much ignore the comment.
2. Because your email is (often) associated with the comment, it sorta makes you look bad.
3. Worst of all (to me), you let go an opportunity for either or both of us to learn.

This isn't a general ban on comments--I could do that without posting. This is an attempt to point out that if I wanted the conversation to be one-way, I wouldn't leave comments turned on in the first place. This is the best mechanism I know of thus far for you to call me out on my arguments--why waste your time otherwise?

James Bach recently blogged about something I've been saying in conversations with friends and conference attendees: there ain't no such thing as a "best practice".

He lays out his points in a letter to his blog readers, and I want to comment on a few of them.

First, "There are no best practices. By this I mean there is no practice that is better than all other possible practices, regardless of the context. In other words, no matter what the practice and how valuable it may be in one context, I can destroy it by altering things about the situation surrounding the practice." James hits the nail on the head with this one: any practice, taken out of context, can easily be turned from "best practice" to a "worst practice" without too much difficulty. The patterns guys had it down: A Pattern, or let's call it practice, so that we can talk more about concrete things, is a Solution to a Problem within a given Context that yields certain Consequences. You cannot avoid this basic relationship. (The patterns guys then wanted to take practices, examine them across domains, and find the commonality and elevate it so that we could apply them in a domain-independent manner; hence the reasoning behind the Rule of Three, which so many pattern "writers" seem to miss.) It makes sense, even on an intuitive level: I walk into a doctor's office, and say, "I have a cough". What's the Best Practice here? Meds? Diet and exercise? Immediate surgery? It clearly depends on the context--other symptoms, the pervasiveness of the cough, the reasons behind the cough, and so on. Doctors who fail to establish the Context before offering a Solution are often called Quacks... or sued for malpractice.

He goes on to say, "Although some things that don't exist can be useful as rhetorical signposts, "best practice" is not one of them. There is nothing honorable you get from pretending that a practice is best that you can't also get from suggesting that a practice may be good in a specified context, and making a case for that. Sure, there are dishonorable things you can get from "best practice" rhetoric-- say, causing a dull-witted client to give you money. If that has tempted you in the past, I urge you to reform." Unfortunately, the temptation is too strong, particularly for those who are pushing a new platform upon the world. Java got tremendous success from pushing patterns rather than canned solutions (and I think we pushed too many patterns, not enough practices, to be honest), and so now it seems a requirement for any new platform that in addition to the platform, you need to have an established set of practices with it to help guide the newbies to the platform. After all, how comforting does it sound when somebody seeking to sell you on a new platform, when asked "So how do I use this thing best?" turns to you and says, "We really don't know yet since there's not a critical mass of people using it yet"?

"It has a chilling effect on our progress as an intellectual craft when people pretend that a best practice exists. Best practice blather becomes a substitute for the more difficult, less glamorous, but ultimately more powerful idea of learning how to do your job. By "learning" I mean practicing the skills of identifying and solving patterns of problems we encounter as testers. Of course, that will involve patterns of behavior that we call "practices". I'm not against the idea of practices, I'm against pretense. Only through pretense can a practice that is interesting in a particular context becomes a "best practice" to which we all must bow down." Again, I'm fond of the patterns terminology here, because it clearly highlights the problem he's stating here: if we think we have a "Best Practice" to a particular problem, in other words, making it a two-part tuple, it becomes a deceptively simple list: we only need state all the Problems, and the Solutions will be apparent, since when would you choose not to use a "Best Practice"? When you list it out as a four-part tuple: Problem, Context, Solution and Consequences, it becomes more clear that a particular Problem doesn't have one "Best Practice", but depends entirely on Context and desired Consequences.

I would challenge anyone to name a "best practice" for which there is no situation which makes the "best practice" a "worst practice". To use James' example:

"A doctor who prescribes a drug without examining the patient is committing malpractice. Isn't that obvious? Would you respect such a doctor? Why should we respect people who prescribe practices without regard for the problems faced in a project? The answer comes back, "What if the doctor tells you to eat right and exercise?"

People often cite EJB as a terrible technology. Bullsh*t. People who do that are missing the point. (Even Rod Johnson agrees with this point, or at least he did in a private conversation at The ServerSide Symposium in 2004.) The problem with EJB was that it was highly oversold: another case of "best practices" gone awry--most projects don't need EJB, despite the advice from EJB vendors. (Hmm....) EJB offers a much simpler programming model when dealing with two-phase commit programming against transactional resource managers, particularly given the context of seeking something industry-standard (for fears of new programmers having to burn all kinds of ramp-up time when they're hired). That's not really the problem space that Spring seeks to solve. (Leaving the reader to perhaps realize that maybe there's a place for both Spring and EJB in the world?)

Why the frenzy to use the term, if it has so many things wrong with it? Easy: "Best Practices" are easy to sell. Who wouldn't want to hire somebody who practices only "Best Practices"? Who would want to hire somebody who doesn't? It's an easy term for managers and HR practitioners to latch onto, and this is why most of the time you see unsophisticated speakers and tech leaders climbing all over themselves to use the term. Come on, admit it, which title sounds better and more "bang for your buck" at a conference? "J2EE Best Practices" or "Patterns of J2EE"? Most developers will pick the first, every time. And, worse yet, not realize they're being sold a bill of goods.

If you find yourself tempted to use the term, stop and examine your rationale for doing so. Are you really asking somebody what the best way to use something is, without regard to context? Or are you implicitly seeking to push your own agenda? As a speaker, I routinely get questions like, "Is it a best practice to ... ?" that are followed up by, "But what about when ....?", in essence seeking to know if I change my advice when the Context is different than what they think I'm thinking about. And usually, yes, it does.

Challenge to the reader: the next time you see somebody use the term, "Best Practice", ask yourself (or them) if you can come up with a situation (a Context) where it would be a "Worst Practice" instead. If you can't, or if they can't, it's probably indicative that you--or they--don't quite "get it" yet. Or, more likely, that they've just never seen a situation where it wouldn't be applicable... which then makes me question exactly how much this particular practice has been used. Think it's a silly exercise? Almost all of the great technology books in our industry have either explicitly or implicitly brought this point to the forefront of the book, even to the point where the contradict themselves sometimes. Still not convinced? Then how about this: after you can begin to see the separation between Problem, Solution, Context, and Consequences, you may be able to stop listening to "experts" and start making up your own mind.

Context matters.

Elliotte Rusty Harold blogged about the WS-Addressing specifications reaching Candidate Recommendation status, and did a bit of editorializing along the way:

These specs are seeing some serious pushback within the W3C. The problem is that there already is an addressing system for the Web. It's called the URI, and it's not at all clear that web services addressing does anything beyond URIs do except add complexity. In fact, it's pretty clear that it doesn't do anything except add complexity.

Here's the problem. Web Services Addressing "defines two constructs, message addressing properties and endpoint references, that normalize the information typically provided by transport protocols and messaging systems in a way that is independent of any particular transport or messaging system." In other words this is another example of the excessive genericity problem, just like DOM, and remember how well that worked. One of the big fundamental problems with DOM was that they tried to develop an architecture that could work for all conceivable programming languages; but developers don't want and don't need an API for all programming languages. they want an API that's tailored to their own programming language. This is why language-specific libraries like XOM and Amara are so much easier to use and more productive than DOM.

Web Services Addressing is trying to define an addressing scheme that can work over HTTP, SMTP, FTP, and any other protocol you can imagine. However, each of these protocols already have their own addressing systems. Developers working with these protocols don't want and don't need a different addressing system that's marginally more compatible with some protocol they're not using in exchange for substantially less compatibility with the protocol they are using. Besides nobody's actually doing web services over anything except HTTP anyway. Doesn't it just make more sense to use the well understood, already implemented debugged HTTP architecture for this instead of inventing something new?

For example, consider your canonical "push" model; as it stands right now, there is no way to do the virtual equivalent of a classroom environment: multiple clients (students) all passively receiving content distributed in packets from the server (instructor). What's more, that distribution model is essentially a broadcast scenario with zero guarantees of delivery--if a student nods off in class, does the instructor care? Not normally, no, and certainly not to the expense of the other students in class. Broadcast scenarios are a powerful argument against HTTP, since to try and replicate this either

• the clients have to poll continuously for updates, or
• the server has to become the client, and constantly "push" the various elements out to the clients... er, servers... whatever, taking whatever firewall/security issues might be in between them into account (which is why the client-polling scneario is usually the way people go)

Look, at the end of the day, the WS-Addressing spec only requires the Action header, which serves the exact same role as the HTTP verb does: it simply provides a way to describe what the intended action for the message should be. Everything else is optional in the specification, including the To, From, ReplyTo or FaultTo headers (which use the EndpointReferences, the "virtual addresses" ERH is railing about)--which enable flexibility in message responses that HTTP simply cannot provide, highly useful in a workflow situation--or the MessageId/CorrelatesTo headers--which provide the ability to "thread" messages together, something that HTTP could only do with the introduction of cookies, something that Fielding argues against in a major way as it destroys the basic principles of a REST-based system.

In particular, I take issue with the idea that "nobody's actually doing web services over anything except HTTP anyway". If that's the case, somebody had better tell the messaging vendors, like IBM or Sonic or TIBCO or Fiorano, because they seem to be investing a lot into the XML services standards in an effort to help build that exact integration infrastructure that CxOs have been pursuing with all the zeal of the Holy Grail for about forty years now. I can think of four consulting clients off the top of my head that are using XML services over something other than HTTP, and will probably continue to do so for a long time to come. Guess they must just be trying to overcomplicate their lives, even though SOAP-over-TCP and SOAP-over-FTP actually cut the lines of code they had to maintain because they no longer had to build a complicated polling process. And as for "Doesn't it just make more sense to use the well understood, already implemented debugged HTTP architecture for this instead of inventing something new?", shortly, no, it doesn't. There's no sense in trying to take bits that were designed for a distributed hypermedia system (Fielding's words, not mine) and trying to bend it to fit a problem space that isn't distributed hypermedia. Can we learn from the REST architectural style? Absolutely--and the new WS-* specs, including SOAP, do exactly that, favoring self-descriptive messages over RPC calls as the principal abstraction to deal with. But does that mean we tie ourselves solely to HTTP? Oh, hell no.

Barely hidden between the lines in Elliotte's post is a general accusation that the WS-* guys are deliberately overcomplicating things. Frankly, I think that's an unfair categorization of what's been going on. SOAP 1.1 was complex, oh, Lord yes. SOAP 1.2 is actually fairly simple, all things considered, despite the perception you might get when you look at the spec and see three parts and a hundred or so pages instead of a single 30-page document (as SOAP 1.1 was). SOAP 1.2 standardizes a basic message format, with room for extensions (where the rest of the WS-* stack goes, for the most part), and provides a standard fault structure so that not everybody needs to define their own custom fault formats. (This is important if the fault is at the infrastructural level, not at the application level.) Everything else layers directly on top of SOAP, and frankly, if you don't need it, don't use it--the WS-* specs try very hard to be composable, meaning if you don't need a particular element, you don't use it and you don't pay for it. In fact, some of these specs (WS-Eventing, for example) are simple enough that you could implement it by hand without any help (Axis, BEA, etc) whatsoever.

Don't let a tempting political quantity (the basic desire to mistrust the big vendors and think they're just out the screw the little guy) cloud your vision over what's going on in the industry. The big vendors may very well be out to screw the little guy, but that doens't mean that everything they do isn't useful. If you build a REST-like XML service, you're actually following right into the "new" XML service model, and if you slap a SOAP:Body around your message and a SOAP:Envelope around that, you'll be wire-compatible with other SOAP 1.2 endpoints. Even better, if and when you need reliability, workflow capabilities, or integration with somebody else's WS-* stack, you're already primed to go. And wasn't that the point of all this stuff in the first place?

Although I've known for a bit, I couldn't say anything until now, when I just received the official welcoming letter: I'm a part of the JSR-277 Expert Group, the so-called "Java Module System" JSR. Although you can read the full spiel on the JCP website, the nuts-and-bolts part of this story is simple: we (or at least, I) want to fix the horribly busted component model in Java. Or, rather, the lack of any such thing, beyond what the J2EE world offers (which isn't much).

To put it into EG Lead Stanley Ho's words from the JSR-277 home page,

The specification of the Java Module System should define an infrastructure that addresses the above issues. Its components are likely to include:

1. A distribution format (i.e., a Java module) and its metadata as a unit of delivery for packaging collections of Java code and related resources. The metadata would contain information about a module, the resources within the module, and its dependencies upon other modules. The metadata would also include an export list to restrict resources from being exposed outside the module unintentionally. The metadata may allow subset of exposed resources to be used by other modules selectively.
2. A versioning scheme that defines how a module declares its own version as well its versioned dependencies upon other modules.
3. A repository for storing and retrieving modules on the machine with versioning and namespaces isolation support.
4. Runtime support in the application launcher and class loaders for the discovery, loading, and integrity checking of modules.
5. A set of support tools, including packaging tools as well as repository tools to support module installation and removal.

We also expect the Java Module System to expose the public J2SE APIs as a virtual module in order to prevent unwanted usage of the private APIs in the implementation.

There's some high-powered folks on this JSR, as there was on my last EG, such as Stu Halloway, David Bock, Doug Lea, Sam Pullara and Hani Suleiman (gotta be careful about emails to Hani, though, or I might find myself the subject of a weblog entry and I dunno if my fragile ego could handle that...). I'm looking forward to working on a JSR with Stu, with whom I've not closely worked since Stu left DevelopMentor to go his own path, particularly since I've been... err... disagreeable, shall we say?... with his business partner. Not only that, Stu appears to have taken a deep hit of the dynamically-typed languages Kool-Ade, and I always welcome reasoned debate with somebody who's perspective wildly differs from mine.

Once again, I think my major contribution will be the experience of the .NET world, and their experiences with assemblies. It will be particularly interesting to see how Java Modules will or won't closely emulate assemblies, and to be 100% honest with you I'm not sure if it would be a Good Thing or not if they did. I think there's definitely some goodness to how assemblies work, but there's also some interesting feedback filtering through the collective .NET unconscious that seems to disagree with my own perceptions.

All in all, it's going to be an interesting ride. Wish us luck--this is probably one of the more influential JSRs in the JCP for Dolphin, as it'll change the packaging and deployment models for both J2SE and J2EE (and beyond), so if we screw this up.... *shudder*

BTW, if you know of a good component model beyond Eclipse, NetBeans, .NET or OSGi, please drop me email and tell me why you think it's something I should look into. I won't promise anything, but obviously the more experience we can draw upon, the better the chance we have of the final results not... well, not sucking.

Duane Gran emailed me with his thoughts on adopting Ruby-and-Rails into his shop, only his thoughts on the matter are a bit different from the usual rant; he's looking at it from the management perspective, and has some good ideas on when and why to adopt... or not to adopt... a new programming language. Specifically, he spells out: The decision to change programming languages, databases and operating systems shouldn't be taken lightly, but when the issue comes up the approach should be analytic. Be wary of resume-driven development initiatives, architectural advice from vendors, marketing hype and buzzword compliance. That your development team is more productive with the new technology is all that matters. ... I suggest changing architectures only when the following factors align:

1. The technology is proven in your development environment
2. The installed user base is small for your application
3. You are still in a development or prototype stage that won't endanger a production system
4. Your developers want to learn the technology for the right reasons and they have a firm grasp of the code base

I like that list. I could probably add to it, with concerns whether the technology will be somehow integratable/interoperable from your legacy platforms, but I think that these issues are probably the first hurdle to pass--and, frankly, I think will be the hardest hurdle to pass, particularly given his caution against "resume-driven development initiatives". (I like that phrasology, Duane--don't be too surprised if you hear it on an $NFJS panel sometime.

So I'm flipping through some old weblog entries, and I run across this one:

So when is it a good idea to use XML for your data? The easy answer is that you should use XML when it is likely to be easier (in the long run) than creating your own parser. Using XML carries some cost. XML is verbose, and parsing is guaranteed to be slower than a custom parser. Why is XML such the rage then? Aside from the hype there is one very good reason to use XML. For many types of data, it is easier to just load the data into a DOM and extract the information from that, than it is to write a custom parser. That means less time spent debugging code, more time spent focusing on the problem at hand.

1. He originally chose to use XML as the format for Ant scripts because he didn't want to write a parser, and
2. He really regrets it and apologizes to the Java community at large for it.

The problem, in the case of Ant--and its successors, like MSBuild--in using XML is that it is a strictly-hierarchical format, and not everything follows a strictly hierarchical format (even though it might seem to at first). More importantly, XML is a hideously verbose format, and the "self-descriptive" tags that everybody blathers on about are only self-descriptive to carbon-based life forms (and then only if semantically-rich terms are used for the tag names). For example, does this "self-descriptive" XML have any meaning to you?

<p><a>34</a><s>046604143</s><ph>42049941499<ph></p>

So when is it a good idea to use XML for your data? My criteria are a bit more stringent:

• When your data is naturally hierarchical to begin with
• When exchange with foreign platforms (which is to say, platforms not native to what you're currently authoring in) is important
• When pre-existing tool support (XSLT, XML viewers, import/export utilities, etc) is of paramount importance

By the way, scripting languages (like Ruby, Python or JavaScript) make a terribly convenient way to do data storage/manipulation that still doesn't require writing a parser or custom data format--witness the astounding success of Ruby-on-Rails in this area to see what I mean. Combine this with the ability to embed them in your .NET, Java or C++ code, and you have a really strong argument against using XML to "avoid writing a parser". Look at what Groovy does for Ant scripts, for example (Pragmatic Project Automation).

John Robbins recently blogged about an "amazingly cool" bit of .NET TraceListener magic sent to him in an email:

Josh Einstein sent me a mail about his amazing TerminalTraceListener. If you add TerminalTraceListener to your application, you can telnet into your application and monitor tracing live no matter where it is. How amazingly cool is that!? Josh also added a second TraceListener, SyslogTraceListener, that pumps the traces to Kiwi Syslog Daemon.

What this really underscores, however, is how John's debugging capabilities have been limited (however slightly) by his unawareness of the Java space. John is not a stupid person by any stretch of the imagination--his books on debugging leave me in stunned jaw-dropping silence every time I read them--but it sounds like he thinks could have used these two long before now, and he could have had them (without even having to write them, in fact) had he known about log4j or log4net before now.

Which leads me back to my point: you don't have to be a hard-core Java developer to learn something from the Java community, and vice versa. Take a day or two, learn the platform you don't routinely write code on, and take a day or so every month to look around at the tools and technologies that are out there. I think you'll be amazed at how rich and powerful the "other guys" are, and your own skills will grow immeasurably as a result.

A bit late, but I realized after I posted the Recommended Reading List that I forgot to add Mike Clark's Pragmatic Project Automation, a great resource for ideas on how to automate various parts of your build cycle... and, more importantly, why this is such a necessary step. Although nominally a Java book, there's really nothing in here that couldn't also be adopted to a .NET environment, particularly now that $g(NAnt) and $g(MSBuild) are prevalent in .NET development shops all over the planet.

Most importantly, Mike indirectly points out a great lesson when he uses $g(Groovy) to script $g(Ant) builds: that you don't have to stick with just the tools that are given to you. Automation can take place in a variety of ways, and scripting languages (like Groovy, or Ruby, or Python...) are a great way to drive lower-level tools like Ant. Stu Halloway has begun talking about the same concept when he discusses "Unit Testing with Jython" at the $NFJS shows. Coming from the .NET space? Then think about $g(IronPython), or even the JScript implementation that comes out of the box with Visual Studio.

All in all, a highly-recommended read.

Dion blogged about $g(Parrot) a while back, and it triggered an interesting thought: we already have IKVM, a JVM-running-on-the-CLR, is it possible and/or practical to do a Parrot-running-on-the-CLR or Parrot-running-on-the-JVM? That would do some interesting kinds of interoperability scenarios between Parrot's targeted dynamic languages and the library-rich platforms of Java and .NET....

(Note that this is a reprint, so to speak, of the same entry on the old weblog, but I wanted to kick the Reading category off with a reprise of what I'd written before.)

I've been asked on several occasions (from students, from blog readers, and from a few friends who happen to be in the business) what my recommended reading list is. I've never really put one together formally, instead just sort of relying on impromptu answers that cover some of my absolute favorites and a few that just leap to mind at the time.

Enough is enough. It's time for me to post my recommended reading list, broken out for both Java and .NET programmers. (If you're of one camp, it's still worth reading books on the other camp's list, since the two environments really are Evil Twin Brothers.) And I've left my own books off the list, because I think it's rather forward of me to recommend them as recommended reading--naturally, I think they're all good, but whether or not they make the cut of "recommended reading" is for others to weigh in on, not me (at least not here). (Update: several commenters on the old blog suggested it was not out of line to recommend my own books if I thought they were worth recommending, so I added them.)

Java Recommended Reading list:

• Effective Java by Bloch.
• Java Puzzlers by Bloch and Gafter. You think you know the Java language? Try it. (Makes for great interview question fodder, and for that reason alone practicing Java programmers should have a copy on their shelf.)
• Effective Enterprise Java by Neward. (Had to do it. )
• Concurrent Programming in Java (2nd Ed) by Lea.
• Either Inside Java2 Platform Security by Gong or Java Security (2nd Ed) by Oaks.
• Component Development for the Java Platform by Halloway.
• Inside the Java2 Virtual Machine by Venners.
• Java Development with Ant by Hatcher and Loughran.
• Either Java RMI by Grosso or java.rmi by McNiff and Pitt.
• Server-Based Java Programming by Neward. For obvious reasons. Actually, I still think this book is applicable if you want to understand the reasons why an app server makes some of the restrictions that it does, but I freely admit that I don't think I did a great job of "closing the loop" on that and finishing the book with a good summary that ties everything together. Ah, retrospect....
• Servlets and Java Server Pages by Jones and Falkner, possibly Java Servlet Programming (2nd Ed) by Hunter, if you aren't planning to use JSP. (Jason's legendary bias against JSP, right or wrong, puts him somewhat out of tune with what a majority of Java web-client shops are doing. That said, it's a great servlets resource.)
• AspectJ in Action by Laddad. AspectJ represents the best of the AOP solutions, IMHO, and this book represents the best of the AspectJ books available.

.NET Recommended Reading list:

• C# In a Nutshell (2nd Ed) by Drayton, Albahari, and Neward. For obvious reasons.
• Advanced .NET Remoting by Rammer.
• Essential ADO.NET by Beauchemin.
• Inside Microsoft .NET IL Assembler by Lidin.
• SSCLI Essentials by Stutz, Neward and Shilling. For obvious reasons.
• Debugging Applications by Robbins.
• Inside Windows 2000 by Russinovich and Solomon.
• Essential COM by Box. (Yes, I mean Essential COM and not his more recent Essential .NET book. The first chapter of Essential COM is probably the best well-written technical prose I've ever read in my life, and everybody who ever wanted to write reusable components in C++ needs to read it to understand why C++ failed so miserably at that goal. Once you've seen that, you're ready to understand why components are so powerful and so necessary.)
• Essential ASP.NET by Onion.
• Expert C# Business Objects or Expert VB Business Objects, by Lhotka. Not an intro to business objects, per se, but a great read on how to build a framework. Pay close attention to how Rocky handles distribution; he avoids the canonical problems of "distributed objects" by not distributing objects, but instead making them mobile objects.
• The Common Language Infrastructure Annotated Standard by Miller
• Programming in the .NET Environment by Watkins et al.

C++ Recommended Reading list:
(For the twelve people left in the world still writing C++ code, anyway.)

• The C++ Programming Language (3rd Ed) by Stroustrup.
• Effective C++ (1st, 2nd or 3rd Ed) by Meyers.
• More Effective C++ by Meyers.
• Effective STL by Meyers.
• Inside the C++ Object Model by Lippmann. You don't know how C++ works until you've read this cover to cover. Twice. And peeked at everything under the hood with a debugger, just to make sure Stan's right. Seriously.

Database/Relational Storage Recommended Reading list:

• Introduction to Database Systems (8th Ed) by Date. Heavy on theory, and for that reason alone should be read at least once by any practicing programmer who thinks they understand SQL and the relational world.
• SQL for Smarties (3rd Ed) by Celko. Actually, you need to own just about everything by Celko.
• Principles of Transaction Processing by Bernstein and Newcomer.
• Transaction Processing: Concepts and Techniques by Gray and Reuter. What to read when you're done with the Bernstein and Newcomer book and still want to know more about the Zen of Transactional Processing.

Security-related Recommended Reading list:

• Secrets and Lies by Schneier.
• Either Cryptography Decrypted by (can't remember the name offhand), Practical Cryptography by Schneier and Ferguson, or Applied Cryptography (2nd Ed) by Schneier. The first is a lightweight introduction to the subject, the second is a more detailed introspection, the third required reading for anybody who wants to be a security wonk.
• The Code Book by Singh.
• Hacking Exposed (5th Ed), by McClure, et al.
• Exploting Software, by Hogland and McGraw. The most fun book in the list, if you ask me.
• Reversing by Eilam. Who says unmanaged code is "safe from reverse-engineering"?
• The Art of Deception, by Mitnick

Operating System/Platform Reading list:

• Windows Internals (4th Ed) by Russinovich and Solomon. Actually, any of the last three editions (2nd, 3rd, 4th) is awesome, so look for 3rd Ed in a bargain bin and pick up a great bargain.
• Operating Systems (2nd Ed) by Tanenbaum. The original "Minix" book. Taught me the basics of how an O/S works, and the basic concepts are still applicable to this day.

Platform-agnostic Recommended Reading list:

• Design and Evolution of C++ by Stroustrup. It's fascinating hearing how a language develops over time, and what was behind some of the decisions in the features of the language. For example, why did multiple inheritance come before templates or RTTI? Not because it was more important, but because Stroustrup wanted to tackle MI first because he wasn't sure if or how he could do it. He describes that as a great regret, that he didn't do templates first.
• Component Software (2nd Ed) by Szyperski.
• Rapid Development by McConnell. Read this before you read any of the Extreme Programming books, because this book describes a whole taxonomy of what I think a lot of people are reaching for in agile and other methodologies.
• The Inmates Are Running the Asylum by Cooper.
• The Invisible Computer by Norman.
• Refactoring by Fowler.
• Design Patterns by Gamma, Helm, Johnson and Vlissides.
• Pattern Oriented Software Architecture, Vol 1 by Stal et al.
• Pattern Oriented Software Architecture, Vol 2 by Schmidt et al.
• Patterns of Enterprise Application Architecture by Fowler.
• Enterprise Integration Patterns by Hohpe and Woolf. Excellent discussion of message-based architecture. I personally think the title is something of a misnomer, but it's understandable since message-oriented communication is the easiest means by which to integrate heterogeneous systems.

Note that this list will undergo revision and change as I continue, so I'm putting a link to this item in the links column in the sidepanel to the left for easy reference. For now, I'm just listing them out as they come to mind. Later, if I have time, I'll put paragraphs of detail behind them so you can know why I recommend them. (Updated on 13 Feb 2002) (Moved to this weblog 21 Aug 2005) (Updated 5 Oct 2005)

Look for more book reviews and recommended reading via the "Reading" category on the RSS feeds. There's undoubtedly titles that I'm forgetting, and I'm hoping I'll get around to blogging more about the books I'm reading now, including Ruby (the Pickaxe book and the Rails book), some other titles in the Pragmatic series, as well as some WS-*-related stuff and (of course) the staple C# and Java stuff. And of course I'm always open to suggestions of new and interesting technical titles to peruse....

Update: Steven Rockarts pointed out that Rocky's "Objects" books are missing, as is Fritz's Essential ASP.NET. Added. (He also lists Object Thinking, by West, but I don't care for that book--too Zen, I think, for most readers.)

Well, apparently I've created quite a stir in the blogspace by not immediately rushing to embrace Ruby-on-Rails, and I'm of two minds as to the larger impact.

For starters, allow me to respond, one last time, to what Justin and Dion and Glenn have written:

• "Pretty clearly, Rails' biggest benefit is Ruby itself. ... Dynamic languages like Ruby provide for eloquence of expression and compile-/run-/deploy-time extension of the core framework abstractions. ... extending classes at runtime ... is powerful, and hard to do in a statically typed language." Actually, Justin, as I think some of the feature set listed for C# 3.0 demonstrates, it's not that hard to do at all in a statically typed language, particularly considering that we don't want to do it at runtime, but at compile-time, so to speak. (I've yet to see a Rails demonstration that changes the type at runtime--it's all been done at edit-time, which in Ruby is the logical equivlent of compile-time.)
• "Lots of people have written about Ruby’s suitability for creating DSLs. When it comes down to it, Ruby’s ext