I think I finally figured out one of my main aversions to XML parsers in every freakin' Java program out there. To use the software, you used to have another technology you'd have to download and familiarize yourself with before using. To maintain the code, you have to not only figure out how a parser works -- and sometimes make sure you grabbed the right one -- but you also had to learn XML, XSL, XPath, SAXm and all sorts of other technologies in order to read from a stinkin' text file. As I've said before, XML is great only if anonymous developers are going to be interfacing with your product.

The theory here, of course, is awful similar to Joel Spolsky's idea of barriers to entry article. Here's a rather lengthy quote.

Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won't be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer.

This calculus [calculus? -R] means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales.

And we quickly see that we have several barriers when using XML. When creating code that depends on XML, first your developers have to understand the alphabet soup of XML. Then they need to understand need to understand parsers (luckily you no longer have to search for one; Sun's already made the decision for you and packs one with recent JVMs. Of course if you're releasing for Mac Classic or Microsoft's JVM, both 1.1.x, you're in trouble).

Even if these issues seem trivial, I'd extend the idea of barriers to entry to say that your code will be twice as difficult and resource intensive to maintain with each barrier you add.

That's why I like using plain text (most Java programmers understand I/O) or an RDBMS (it's relatively easy to learn SQL even if you don't know it already). More importantly, that's why I like abstracting data read/writes into objects that aren't dependent on the underlying tech at all, so that your programmers only have to know one tool -- object oriented programming. Then you can have one feller who knows the appropriate read/write tech -- be it file I/O, SQL/RDBMS admin, or XML -- and Java who maintains that layer. And your app's goals will decide which you use.

This is also, of course, why managers, whether they know it or not, prefer simple, one tech solutions. This is also why managers love Microsoft. You want to make this in php and mySQL on Linux? What if the next open-source weenie knows mySQL and JSP? Or Postgresql and Python? Or Postgresql and Perl? What's the standard open-source solution? (Of course each of those require another tech to talk between the dbms and the web page.) Developers with "pet techs" make maintenance nightmares.

With Microsoft, it's easy. You use ASP, vbscript, ADO, and either MS-SQL Server or Access, depending on size. You install on Win2k. Done. If you want to be "forward thinking", you just onto the blee/lea/ding edge and use ASP.NET, VB.NET or C#, ADO.NET and Windows Server 2k3. There's one set of technologies. There are tons of people that know these technologies. They all know the same set of technologies. Over the long haul, it's cheaper to pay the piper for licensing to buy into the easy to maintain, all-choices-made-for-you environment.