So some background...
I am an independent Integration Consultant. I've worked in various industries and with various Middleware platforms. Most of my experience lies with webMethods and TIBCO but I've worked with many different technologies and development tools.
I've done a lot of hands on development and over the years have come to appreciate and despise certain features and functionality of the tools and technologies.
If you don't know what webMethods or TIBCO is, then this post is probably not for you. This post is mostly a rant and exhaust for my frustrations with these tools and to get input from other developers. However, it is also an attempt to highlight these issues with the hope that the vendors like SoftwareAG and TIBCO will take notice and possibly start addressing them.
webMethods (SoftwareAG)
The IDE
Scrolling in the pipeline window
So lets start with the IDE. The latest from webMethods is Designer and is an Eclipse based IDE like most other tools these days. That's all well and good. I like Eclipse and Designer does a decent job at making everything work well together in so far as it's possible. The first problem is a bit fundamental to wM development in general: service and doctype names and the lack of a smart way of aliasing or shortening these in the IDE itself. Every wM developer knows exactly what I am talking about. During development I spend probably 10 to 20 % of my time scrolling the IDE windows from left to right and back again just to see which service is being called, which subfield is being filtered on, which doctype is mapped etc etc. It can get very tiring and frustrating to run a service and have to scroll to the right everytime the pipeline changes. Sure, if you do your best to use naming conventions and keep names simple and short it gets better but in decent size companies with large deeply nested data models it's impossible to avoid.It seems like a stupid thing to gripe about but one of the selling points of platforms like wM and TIBCO is that development is easy. The (in)famous "no coding required" tagline is still used to this day, and it should all be graphical and drag and drop. Yes, it's all drag and drop and point and click but I bet I can do the same mapping by writing code in 5 minutes which in "GUI" mode would take 3 minutes to actually do the mappings and 5 minutes to do the scrolling from left to right. It's counter productive if the development is based on D&D yet the actual UI is restrictive and forces me to move the mouse around a lot just to see the mappings.
It's one of my biggest frustrations when I'm debugging wM code and the pipeline window has a scrollbar spanning 2000 pixels horizontally and 5000 vertically.
Alas, I don't think this will every change. The servicename etc is deeply ingrained in the wM flow code and changing it will probably break every feature in the platform. So I'll just take this "as is" and just complain about it from time to time.
UI Design
Now to be clear I'm not talking about Design as in "make it look pretty". I don't need glossy buttons or beautiful icons. I do however, need clear indicators of meaning. In java or python IDEs syntax highlighting is one of the most important features since you can quickly glance at code and make a mental map of where things start and end, whether it's a method or loop, etc.wM flow code has something similar and it's OK. I personally don't like the rigid flow structure but it's a peeve, I know some people like it. I much rather have the TIBCO way where I can arrange (style) the code in a more personal way.
Anyway.
One of the first peculiar design decisions I still don't understand is that of greying out unlocked code. In wM, code is read-only by default. If you want to edit it you have to "lock" it. In the latest Designer, wM decided to indicate the difference by making all unlocked code greyed out. See the image below:
The result of course is that it's annoying and difficult to read the code to the point where I usually lock it just to be able to read it. Why oh why did they do this?? The whole "greying out" of code should have been discarded and instead something like a red border or a different color background should have been opted for to indicate the code is locked.
Next in line is the inability to see everything if the code is not locked. For example in labels you have to sometimes set expressions for the branch steps. If the expression involves variables which have long names (see my first point regarding doctype names) the expression will go off screen. No problem, because you can just go in the Properties window, click Label and you should get a big pop-up text area so you can see the whole expression. If the service is unlocked, too bad, can't open up properties. This is terrible. Basically, I can't read ALL the flow code (the expression is an important part of the code) if I don't have the service locked. What if someone else has it locked so I can't lock it? Now I can't read the code!
Next is one of the biggest causes of headaches in all of wM land. The hidden mapping. See, in wM if a variable is mapped in the pipeline it becomes visible in all subsequent steps in the pipeline. So far so good. If I now delete the source of the mapping (input) in a step other than the one containing the mapping, the variable will remain visible in the pipeline as a normal variable even though its source does not exist! So you think you removed an input or variable, you run the code and it's still there wreaking all sorts of havoc on your code.
TIBCO Businessworks handles this sooo much more pleasantly: Within the step the faulty mapping is highlighted. To top it off, TIBCO has a "project validation" function which does a quick check for these sorts of things so before packaging you can quickly run it and catch such bugs. It will point out mapping issues, uncaught errors, etc. In wM we are left to tediously click our steps and investigate the code to find the offending mapping.
A simple "validation check for service" should be enough to quickly find this bug. A service can be validated for variables which are mapped from but which do not exist in the pipeline.
Let's talk about searching. Have you ever wanted to search for a hardcoded value or a variable name? Searching in webMethods is limited to names of wM objects like services, doctypes and schemas. Anything deeper and you will have to click through and read it yourself. And this means clicking each individual hardcoded mapping. You can't simply click on a map step, see the pipeline and in one glance see which values are hardcoded. Hardcoded mappings are indicated by a little "x" icon on the variable name. To see what the actual value is you have to hover over it (gives you a short version) or double-click on it. This gets tedious real fast when searching for something.
I can understand that it's more difficult (or slow) to search the entire code base for some hardcoded value, but it's not even possible to search within a service! I mean come on, it cannot be that hard a feature to implement. A quick search for a substring in any of the mappings or variable names within a service.
As I'm reading this I can see these issues sound like trivialities but for developers like me it all adds up to a frustrating mess of cumbersome development which should be much more streamlined, efficient and productive. Instead I feel restricted and dragged down by the IDE and the webMethods way of doing things. As an independent contractor I often choose certain projects over others almost solely because one uses the wM platform and the other does not. Of course I don't always have that luxury but still. If this is the sentiment among Integration Consultants (and I am not saying it is) it could have real impact on SoftwareAG. If the software is not as productive as other vendors', developers will be able to do less, in a less efficient manner and development costs will go up. Not only for the project creation but further down the line for maintenance, redesign (I should have mentioned refactoring in wM....one of the most painful processes in wM coding), the compound interest on technical debt, paid in the costs of a project can be severe.
All the issues I mentioned above make the code harder to read, harder to write, and therefore harder to debug and test.
I often find myself longing for the days of simply writing Java or Python and being able to use all the beautiful features of today's IDEs. Syntax highlighting and code completion, refactoring, code generation (I love the ease of "Generate getters and setters" in Java), searching, etc. webMethods is supposed to make development easier and more streamlined. In reality it limits productivity, especially compared to programming languages used in combination of mature, industry proven frameworks like Spring and Django.
In this post I've focused on webMethods and the negative features it has, pointing out how it is done better in TIBCO. I admit I am a bit biased towards TIBCO BusinessWorks, simply because I feel it actually is a better product from a developer point of view. I have no vested interest in either TIBCO or webMethods. I make my living off of both and feel both have their strengths and weaknesses. I do however feel that improvements can be made to make the overall development better and easier resulting in overall productivity and quality improvements. It doesn't even require a lot of development from SoftwareAG to implement but would result in so much more satisfaction for the actual users of the software, us the developers. One of the main things I hear from .NET developers is "Visual Studio and the whole .NET eco-system is so nice to work with and is so easy to use". Big players like MS and Oracle know that to get the momentum, to get traction and reach they must make developers happy, and that is where SoftwareAG and TIBCO are failling.
I really hope SoftwareAG starts paying attention to these issues of the User Experience and the development environment as a whole. There is another bug in the BPM tool of webMethods where the lines in the Process Model don't link up properly to the actual step. Again, this sounds trivial but it feels extremely amateuristic to have these kinds of UI bugs coming from a company like SoftwareAG and it sets the tone for the overall development experience: buggy, amateuristic, unpleasant and cumbersome.
What bothers me is that most of these issues are fixable for a relatively low cost and it would push the potential of the platform as a true Rapid Development Environment. I think webMethods could be a really powerful platform but in its current state I feel it is bogging me down, especially compared to alternatives in the same price bracket.
In my next post I want to point out the things I do love about webMethods, and yes there are many. It's a good middleware platform and provides a truly Service Oriented Architecture right out of the box.
If anybody has an opinion on this or some other story regarding webMethods or simply wants to argue against the points I've made please comment, I would love to hear what the rest of the community thinks.