This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Pipes Dreams

Stefan Tilkov,

Peter Williams on Yahoo! Pipes' lack of a text representation:

Almost immediately i was disappointed in the lack of a textual representation of the data extraction and transformation rules that comprise a “pipe”. Being a programmer by trade i always feel happier when i can use my favorite text editor, not to mention source control, for tasks like these. [...] However, my wife, an ETL expert, assured me that visual editing is the norm for tools such as Pipes.

I saw this coming up again and again recently: While for many models (and programs, and anything in between) having a visual representation is nice when you want to read (or view) it, visual authoring sucks in the vast majority of cases. Sadly, being able to efficiently edit something in a text editor, with versioning and diff support and so on is in general not what impresses those who make purchasing decisions.

On February 26, 2009 8:24 AM, William said:

Another take on this:

On February 26, 2009 11:03 AM, Martin Probst said:

I’ve once worked at a certain very large German ERP software company, which of course, being ERP, totally goes after these BPEL, BPMN, Business-Process-whatever things. And yes, they acknowledge all these problems with versioning of process models, abstraction, reuse etc., but apparently no one is really trying to fix them.

I think one of the reasons is that you’re trying to sell this to business users, and business users are not programmers, so they usually don’t employ the mental rigor that’s needed to come up with good abstractions, even if it’s only something like a function call to a subprocess.

IMHO that’s also the reason why “Excel programming” is both popular and horrible. Popular because you get something done very quickly and are not forced to learn any abstractions, and horrible because you end up with code that has no abstractions whatsoever and reuse is indeed copy and paste.

On February 27, 2009 10:31 AM, Anonymous Coward said:

… but apparently no one is really trying to fix them. And they have good reasons not to fix it. Undocumented serialization formats or creative interpretations of standards (e.g. XMI) are a perfect way to create vendor lock in. This guarantees that customers have to use the complete tool chain from one supplier only.