Philip Eby has some
on the Chandler development team recent decision to drop its
XML-based "parcel" (parcels are components in Chandler) description format
in favor of a pure-Python solution.

There are two interesting lessons in his post:

Of course, the real sin here was
not so much XML per se, as overengineering in advance of requirements. If
you're not developing the feature now, it's best not to make a bunch of
other design decisions based on what you think the feature will need. A little
thing like choosing to put data in XML form can result in a wide variety of
additional costs like:

  • Designing the XML format

  • Implementing a parser

  • Documenting the format

  • Developing a bunch of stuff in the format

  • Evolving and fixing the parser to handle more and more complex use
    cases that weren't thought of previously

  • Productivity losses versus what it would've been with Python

  • Converting all the data once you decide it was a bad idea, or else
    paying the ongoing marketing and education costs to get third-party
    developers over the hump, or the cost of not getting those developers on


I've certainly worked for organizations where the reverse is true, though,
including one that threw away tens of
millions of dollars
trying to replace a small, well-designed Python
application with an expensive piece of "enterprise" crapware. Ah, the
things I could've done with that budget! Well, probably I just would've
given everybody raises and maybe hired a few more people. Or maybe spun off
my group as a company that would sell the software to other companies.
Heck, we could've used it to buy free
sodas for life
for everybody working in the company and got more
value for the investors than what was actually done with the money!