in reply to Client prefers java, but wants to hear a case for Perl

I would play on:

I think you will lose, though. I have tried to argue this exact case with several big clients, and lost all arguments (might be my fault, of course). Try to define a cut-off point to decide how much resources you will spend on trying to convince the client. Otherwise this might become an acquisition resources black hole. (Extremely sorry to say this, but it is my experience.)

Christian Lemburg
Brainbench MVP for Perl

  • Comment on Re: Client prefers java, but wants to hear a case for Perl

Replies are listed 'Best First'.
Re (tilly) 2: Client prefers java, but wants to hear a case for Perl
by tilly (Archbishop) on Apr 17, 2001 at 20:00 UTC
    Ironically even the Java fans that I know have generally bad things to say about VA, but it seems to have a strange appeal to the PHBs...

    Anyways, you might try to find someone who has used it extensively and can give you a view from the trenches about its true resource requirements, instability, bugs, etc. (That person would not be me, but it should not be too hard to find someone, I know that several at IWETHEY liked complaining about it.)

      Oh, I did not say I lost due to "objective" reasons, like technical features, stability and so on. I lost due to a very strong belief of the client that said "I want a standard product from a known company with a strong brand name". I was not able to successfully argue Perl against that belief.

      For the technical perspective: I have worked with VisualAge for Java and WebSphere, and my conclusion is that this combination is a sure productivity killer (we spent days just configuring WebSphere), and unstable on top of that (deployment of EJBs is a true nightmare, with version incompatibilities and everything).

      For more on the WebSphere technical side of this, see this collection of reviews.

      VisualAge for Java is also highly unusual in its IDE approach, at least for those not having a Smalltalk background, and will guarantee a lot of confusion for people coming from a "normal" IDE background. (VisualAge takes the approach that you browse a class hierarchy, modifying attributes of classes and inventing new ones along the way. So, e.g., you will usually work on the source code of a single method only, with the rest of the class not shown in the editor window. To see code in another method, you have to change to a new window (or "frame"), forcing you to decide on a commit/cancel for your changes. But who cares anyway.)

      Christian Lemburg
      Brainbench MVP for Perl

        Are you willing to be slimeball to get your foot in the door? If so then read on for some class A slime politics.

        During the initial process make sure that the superior of the person making the decision knows that their requirements are for a product that they were told has a bad reputation in terms of integration with standard administrative tools, performance, corruption, overhead for configuring, etc. If you can make that more widely known, all the better. But the boss is definitely the person who needs to be informed. After all the desire for a standard product from a known company with a known brand name is basically a CYA response, so make sure that the A is swinging naked in the breeze.

        You will probably lose the contract. Don't sweat it and don't waste too much energy. That is a lost cause against entrenched assumptions and you know it.

        Then every month or 3 send an email to the person who made the decision and that person's boss, asking them how the project is going, how the tool you warned them about is working out, reiterating your original estimate, and saying that while you are disappointed that you didn't get that contract, you would dearly love to get a chance to show what you can do.

        Don't put a lot of work into this. (But if you can get inside information and time your emails to coincide with missed deadlines, major crashes, etc...alternately you could make the emails coincide with what you estimated as in your initial estimate as when you would hit major milestones.) If you are right about their current toolset's deficiencies, their tools will be doing the convincing for you. Your job is just to keep them from slipping into the apathetic belief that this is just how it has to be.

        What you are aiming for is to turn those problems with their toolset into active dissatisfaction, so they are willing on a future project to give you a chance. If you get that chance, then do your best to bid low, estimate the time high, and then overdeliver. You got this chance through dirty politics and there are very likely to be people in the company with considerable investment with the current tools wanting you to fail. But if you succeed in proving yourself well...