Today I discussed a simple problem with a colleague. He wants to design a simple format for representing graphs (nodes and arcs). He said that it's probably going to be XML-based to which I replied that it is a very bad engineering decision (see below for short explanation why and other choices). He agreed to that, but he's going with XML anyway. He said that today's IT industry is full of people "falling" for 3-letter acronyms and that he just wants them off his back. So, from the engineering viewpoint, the better solution has lost because of XML's "psychological effect". I imagine something like "It uses XML, therefore it must be good." Bullshit.
Problem with XML is that it's not very human-friendly and it's complicated to parse. Yes, you have ready made parsers, but you still have to walk the parsed tree. I suggested embedding an interpreted language such as Lua or Tcl. Syntax is definetly more readable than XML, parser is there, the user gets additional power (e.g. programatically constructing the graph instead of tediously enumerating nodes and arcs), and there is no "walking the tree". "Tags" in the scripting language can be bound to C functions and made directly executable, thus constructing the internal graph representation as the graph description is read, w/o subsequent walking of the tree.
The better solution is obvious, he agrees that it's better, but he's still not going to use it because of the "buzzword effect". How many projects have ended up taking the buzzword route, sometimes to their own detriment (I've myself participated in one such project.. I suggested otherewise, but the management decided to go the "3-letter way", and the project was more than half a year late).
Tags: software engineering programming xml
Subscribe to:
Post Comments (Atom)
1 comment:
Agreed.
Many times I've solve a problem that calls for a DB with XML/XSL/PHP... what a waste of time and energy... PHP/MySQL is better... and for god's sakes, if you want portable, just go SQLite.
Marketers who hype up "industry trends" and creating fads like has been done with AJAX and Ruby create constant problems. Each job can be done with different tools, but ultimately, the best people to decide how to do a job is the people who will be doing it, and not hearsay.
I know you've heard that if you code it in/with $BUZZWORD it'll turn out better, but the people who know what they're talking about when it comes to coding make the central coding decisions.
But as for the passive induction of $BUZZWORD in industry (as in your friend who is sacrificing function for form), every employee in every field eventually comes to a decision between doing a job right, or doing it in a way that looks good. Those who make the technology that is slowly immersing society are sadly no different.
Post a Comment