Re: VB vs. Visual Age for Java
>The company I work for has recently decided to move from VB to
>Visual Age for Java (from IBM). Many of the developers here
>feel that that was a wrong decision. I am interested in hearing
>everyone's ideas on this. Pro's con's etc. I won't go into the
>reasons for the decision, so as not to lead the discussion
>in any direction. Thanks, and I look forward to your input.
I would frame my response in terms of moving from VB to Java. Whether it
is a good idea or not depends on several things:
1. What is the current hardware base, and is it to be replaced/upgraded
soon, or is it in the early to middle stages of its accounting lifecycle?
If the current hardware base is largely UNIX, and still early to midpoint
in its cost accounting life cycle, Java may be the best choice. The bottom
line is what will be the total capital outlay and 5 year maintenance cost
for a VB-oriented solution versus a Java-oriented solution? Some cases may
have he UNIX boxes serving as DB servers with app servers being NT or Win2K,
thus enabling a lower cost VB-oriented solution. Also, Software AG and Mainsoft
have a nice array of DCOM for UNIX and mainframes and VB runtimes for UNIX
and mainframes. This allows you to start the move to future repalcement
of UNIX hardware with Win2K hardware as life cycles end. For a given set
of requirements, new Win2K based hardware sufficient to meet the power, reliability,
and scalability requiremnents will almost always be lower in initial and
life cycle cost than new UNIX based hardware that also is sufficient to meet
the power, reliability, and scalability requiremnents.
2. What is the majority skill set of your company's developers - VB, C/C++,
Java, or what?
If most of the programmers are C/C++ folks with VB skills, then Java will
come easily. If most of the programmers are VB with little or no C/C++ experience,
Java will be coding ****. The cost of retraining, employee turnover, lost
productivity during retraining, etc. have to be calculated. Even if you
stay VB, if you past projects have largely been client/server, you and your
fellow developers will need retraining to learn and use OOA/OOD techniques
(yes, VB6 is in practical terms OO, and VB7 will be OO in theoretical terms,
3. Is the change only for new apps, or will old apps be rewritten, also?
If it is for new apps, that allows a more focsued, phased-in approach that
may reduce costs. Also, having a pilot program to verify the hype surrounding
Java may be enough to make sure no other project ever gets done in Java.
The number of failures with Java-oriented enterprise apps is one of the
best kept secrets in IT. If you are rewriting the VB apps in Java, you will
face a lot of additional costs in resources - development & QA hardware,
additional programmers, testers, and documenters. Such costs can be huge,
and jumping in the deep water with Java can be disasterous if it is not done
just right on the right type of applications.
4. What is the total variable cost of a team of VB programmers to achieve
a given list of requirements versus a Java team of programmers to achieve
the same list of requirements?
In most cases, it takes 50% to 100% more Java programmers to do a given project,
from requirements through testing through QA to deployment, than VB programmers.
It is not just a matter of which one costs more $/hr/seat.
I would ask - "Where's the beef?" Where is the objective cost analysis,
the value engineering processes that led to the change? In most cases, I
have found in observing first hand and in confidential discussions with others,
that a solid, objective analysis (engineering, financial, life-cycle, human
resources, etc.) was never done. All too often, it is a mix of IT managers
with little real engineering/technical knowledge following the herd of lemmigns
to the sea, combined with the anti-MS religious fervor they may have on staff.
What results is a huge cost for the comnpany, and reduced financial performance,
which can affect both pre-IPO and post-IPO stock value. Such a solid analysis
may show that Java and other related technologies are indeed the way to go
for your company, but one does not know until the hard work is done.
Java has largely been a failure on the desktop. Sun can barely give away
their Java based competition to MS Office. Yet, users can download it and
use it if they want, they just choose (freely) not to. As for the middle
tier, Java has landed there, hurriedly trying to catch up to MS technologies
which have been there since VB4 was a pup. Yet, Java/EJB/CORBA middleware
is much slower than VB/COM in the middle tier, and with MTS and MSMQ being
free and more mature, the VB solution is more scalable. BTW, when I saya
VB solution, that means mostly VB, with some components being written in
C/C++ where there is a definite advantage that justifies the cost.
For web applications, web classes (which in VB7 next year will be enhanced
to web services) work great for building very scalable web apps, and avoiding
Java (and related technolgies) offers no speed, capability, scalability,
reliability, or cost advantages over VB (and related technologies) in and
of themselves. The bottom line life cycle costs really depend on the costs
incurred in changes within the domains of human resources and hardware, which
vary from project to project. That is what managers are for. To do the
hard work of objective anaylsis and explain them to their teams so everybody
understands why the change is necessary and how they all will get to the
objective together. Which is also why there are so few good managers any
-- Android Development Center
-- Cloud Development Project Center
-- HTML5 Development Center
-- Windows Mobile Development Center