Philip Eby on Java+XML vs. Python and the sin of overengineering

Philip Eby has some comments 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 board

And:

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!