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.