fun with broken tools

I think I have been ranting about that before, already, and… for whatever it’s worth, then and now again I stumble across the same things that keep bugging me in an unbelievable way. Dealing with proprietary programming languages, most notably the one used in the document management software we used to buy a couple of years ago, is one of these “funny” experiences, in several dimensions…

Lack of development tooling

The first and most obvious FAIL, in this case, is the lack of any kind of usable tooling. And, by any, I mean any. Sure, you can get somewhere setting your editor to treat the source code files in this language as JavaScript or C, which slightly does resemble its syntax, but that’s about all there is. Asides this, just imagine all the things a fully-fledged, up-to-date development environment like Eclipse does bring. Think of syntax highlighting, of code completion, of automatically fixing or organizing imports or module structures, of inline browsers for documentation and source code (or, at the very least, having at hand documentation which is both up-to-date and complete), tools for build, deployment, testing, refactoring, all that. Think of it, and then – imagine working without all that. Having just a plain text editor, or a broken and buggy “development shell” inside the software systems client application, and that’s about all there is. Yes. It works. But it consequently lacks all the things that make software development productive. Not even talking about making it “fun”…

Lack of runtime tooling

And yet, non-existing development tooling is a drain to productivity, and drastically reduces the ease of using the environment (so it is an economic problem if you need to have your developers work as effectively as eventually possible because you know they are expensive), but asides that, it’s ‘just’ inconvenient. Lack of runtime tooling, then again, is way worse. Imagine using, say, an application server with a load of custom code modules of your own inside, but lacking any facilities to provide consistent, stable logging – be that because the logging implementation used inside the system does not play well with multithreading (and, consequently, leaves you with a log file consisting of a mess of characters mixed all over), be that simply because parts of the system aren’t capable of writing out log statements with timestamps and, after all, the company that does support that system asks to have three to five project days to just evaluate how long it would take to fix this. Three to five days to evaluate whether or how long to implement working logging? In 2011? This simply can’t be. This, however, gets considerably worse if logging (or, in general, textual output) is the only way to do runtime debugging because the system offers no (zero, none, null) other ways of how to do debugging of running application code. You’re simply lost, especially considering the programming platform does provide rather dangerous concepts like shared objects in a distributed client/server environment (think of something akin to entity beans) as well as “global semaphores“) which are easy to use, hard to use “right”, and difficult to debug even having good tooling at hand. Trying to find any lock-ups due to objects blocking each other or global semaphores being held without having meaningful tools at hand is virtually impossible, and in such situations, shutting down most of the system, starting up again and hoping for the problem to have gone away this way is the only thing left to do.

Lack of qualified support

And, no, by the way, it’s not just a matter of plain incompetence: We actually even spent money on having the company manufacturing this very piece of software sending us a consultant, spending 3+ days looking at things, trying to analyze our log files to, eventually, come up with nothing helpful except for the prospect to pour way more money into things, again without knowing for sure it will help. Unfortunately, except for this company building that piece of software, there is little to no chance of having additional help. Zero user forums, no mailing lists, no documentation, no books, no nothing – you have absolutely none of the things you take for granted using most of the free or open-source environments, or even other proprietary platforms in example supported by the Oracle Technology Networks communities, by the resources and people at IBM developerWorks or even the Microsoft Developers Network (which, despite my general attitude towards Microsoft, is pretty good if you’re a software developer). In the end, it comes down to a simple solution: There is one “company” you can pay to provide you with engineers who will do whatever they can do, but as soon as you reach the boundaries of these capabilities, you are simply lost. Not talking about how much money gets burned all along this path. So, overally, in our case, performance issues come and may go away again, and in the meantime it’s longing to have something like visualvm or just plain jconsole at hand to track down these errors, and… to hope for these problems to always disappear again without causing too much pain.

Lose/Lose and lack of options

And yet, there’s not an easy solution, given there are 8+ years of customizing and development effort that have been spent on this very platform, a platform which does in no way whatsoever (a) provide a migration path to any successor or other environment or (b) meaningfully support interface and communication standards to at least may be well integrated with supportive additional infrastructure, allowing to eventually build a replacement system one day. It’s a painful walk down a stony migration path, but the other option is to, one day, reach a point where most of the system doesn’t perform anymore, at all. So choices are limited, and the only thing to eventually learn again is: If anything else fails, at the very least go with a platform that uses programming language technologies “common”, market or industry approved, and stay the **** away from any proprietary development languages… otherwise, chances are rather good that, as soon as you hit a certain border, your productivity is going down the drain, as goes the chance to get any “real” work done, as goes your motivation (slowly being replaced by frustration as time passes), or, overally speaking: You’re likely to pay, sooner or later. And we’re not just talking about support fees here.

6 thoughts on “fun with broken tools

  1. Well, really nice article. I can truly imagine the pain. But i have to disagree in one point. The problems you mentioned are imho not caused by strange / weird / … “programming language technologies”, but are caused by lack of documentation, standardized (!) data formats, and of course openness of those technologies in general. If the latter requirements are met then you do not have these problems no matter how strange or “uncommon” ( ;) ) the involved technologies are.

  2. @Ralf: I partly agree. Documentation – yes, indeed. The amount (and quality) of documentation at hand is way too limited to be of real help especially when it comes to use cases which are “uncommon” (yet possible) in that environment. As far as open-ness is concerned however: Sure, standardized data formats and open technologies would be of great help. But in case of this very language, from a rather pragmatic point of view, it “just” would help having tooling or some sort of “tooling support” made available by the provider of that very technology. Knowing that the most expensive piece of software in a given environment also is the one most difficult (least productive) to work with from a developer perspective is simply painful and rather hard to accept. Being proprietary, in this situation, only makes things worse because there aren’t any third-party tools at hand to fill this gap…

  3. Yes, but *standardized* proprietary software (e.g. C# :D :D :D ) is at least openly and cleanly documented. Thus, in cases the company do not have helpful consultants or is way too expensive you are not totally lost (when compared to the situation where nothing is sufficiently documented / standardized).

  4. Well… for exactly _this_ reason I wouldn’t count C# as a proprietary language here. It has a community, there are at least two different implementations (Microsoft, Mono), it is well documented, and, despite copyright and patent “concerns”(?), the language itself is “somewhat” open. Things… can be _way_ worse than this. Imagining a language which seems “fully-featured” yet it is not, due to various reasons (and be that because vast loads of its functionality are either undocumented or untested or “just there for debugging purposes and never to be used in a productive environment”), is way more painful. And, after all, as there’s no one else using it, these issues are completely unlikely to ever get fixed. Fail. :/

  5. Anyway, if all data were stored in standardized formats you would have at least a migration path without the need to use that proprietary (broken?) language / technologies. That was the point i tried to make.

  6. Yes and no. :)

    Actually, in our specific case, data storage is a problem, but it’s not the biggest one. Most of the data lives either inside a large file system (with a structure which is somewhat bizarre yet, to some degree, predictable), talking about “file” data (PDF, HPGL, DOC, …), or inside an RDBMS as far as document metadata, workflow information, … are concerned. There is no real “proprietary” data format involved, at the moment. Asides for the database schema which leaves a lot to be improved, the RDBMS itself might be reached more or less easily using JDBC, ODBC and tools that come in handy here. Automatically or manually traversing the file system also ain’t that difficult. The problem, worst of all however, is the customization logic implemented inside the system that usually keeps track of all these data. This is a couple of man years worth of work, pretty strictly tied to the “framework” that comes with the “platform” itself (lacking better terms for both, here), and structured mainly according to rules the platform more or less explicitely enforces, yet not really structured in a “business” understanding of structuring things. Maintaining it is painful, thanks to the tooling problems… but moving it elsewhere is, too, and be that just because of the overall amount of code. So, talking “lose/lose” again, I guess…

Leave a Reply

Your email address will not be published. Required fields are marked *