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.) | [reply] |
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
http://www.brainbench.com
| [reply] |
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...
| [reply] |