For the past two months we've been working on a project to refactor an Intranet application at work.
The original system used our SAP backend on an AIX/Linux cluster, a Java Based middleware system on NT Server, and a Perl/Apache front-end on Linux. Last year we moved the Java layer off the awkward to administer NT system onto the front end Linux system, and fixed some code, but found that the Java/XML middleware system was so hideously broken it was going to be easier to write a new AppServer from scratch than to fix it.
So in two weeks, I wrote from scratch, a Perl/SAP middleware framework (with a little help from CPAN), and for the last 6 weeks we have been configuring it up to replaced the whole of the earlier Java middleware system. This week it's had some testing in our QA environment, and other than a few xhtml/css glitches it's proved to be very robust, and seems to be passing the tests okay.
I think I've been working on this project on and off for about 50% of the past three years. It's amazing to think that the new bespoke Perl/Apache front end has replaced months and months of work with the commercial Java/XML/XSLT monstrosity.
It doesn't surprise me that there is a lot of crufty Java out there that is supposed to be 'enterprise' applications just because its written in Java using hundreds of thousands of pounds worth of software and written by a couple of inexperienced java programmers who can take home a higher salary than an experience perl specialist because their CV is more buzzword compliant.
Not that I am bitter of course
Re:sounds like an ideal success/switch story
ajt on 2004-09-11T09:53:02
It has already been suggested by others... I've contacted both perl.com and The Perl Review, both are open the idea of an article, I've just got to find the time to write it now!
It's not 100% fair to blame the Java application, though there are many things that are really terrible about it. A deeper fault of the company was to use a Buzzword compliant technology that we had little experience with, instead of a non-buzzword compliant technology that we did know a lot about.
For some perverse reason weak managers prefer to use something "corporate" or "enterprise", instead of something their own staff know about. I know in theory you can get Java consultants to do the job, but in practice it's Perl staff that are doing the work. I don't see the point of having a football team, but forcing them to play Ruby just because it's more fashionable at one point in time.
Re:sounds like an ideal success/switch story
Dom2 on 2004-09-11T14:29:21
I was talking about this at work the other day. We decided that it's basically all down to oracle consultants looking to make money. If there's a shitty in house application somewhere there is probably also some nasty java to go with it and the whole lot is festooned with highly "decorative" (but expensive) consultants.Bitter? Moi?
-Dom
Re:sounds like an ideal success/switch story
ajt on 2004-09-11T14:54:51
I'm not fundamentaly opposed to Java, it's just most of the time when I see it, it smells bad, it looks bad and it leaves a bad taste... I'm sure you can write good code and applications with it, just like I'm sure you can do a good web site with ASP or PHP, it's just a shame that they resembles poo most of the time...
I just wish the PHBs of this world would stop asking for opionion from their own highly skilled staff, and then ignore it. If we hadn't used this particular Java thing, then the project would have been done in half the time, and not needed to be fixed once (3-months work) and rewritten (2-months work).
If you have a football* team, you play with the round ball, not the pointy one. If you don't want to play football, then don't hire footballers...
* Football, or soccer to some people.
Re:Tell us more!
ajt on 2004-09-13T10:41:00
If we ever fix the niggles.... The technology is working fine, it's all the micro details in the implementation that's eating up the time at the moment. But the underlying code has run pretty much okay since day one.
I shall have to see what I can do.
