Re: VB vs. Visual Age for Java


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 2 of 2

Thread: Re: VB vs. Visual Age for Java

Hybrid View

  1. #1
    JJ Guest

    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,
    also).

    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
    a lot of HTML and JavaScript work.

    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
    more.

    Jeff Jones
    Marietta, GA
    Share on Google+

  2. #2
    bharat bharatjuneja Guest

    Re: VB vs. Visual Age for Java


    I too have little similar problems, We are making large client server based
    application on developer 2000 and Oracle, now people don't want to work more
    on D2k, so they want to go for hava based technology , so that same application
    can be work on web also, I f u got any solution let me know also

    bharat


    "JJ" <jeff_d_jones72NOSPAM@hotmail.com> wrote:
    >
    >>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,
    >also).
    >
    >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
    >a lot of HTML and JavaScript work.
    >
    >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
    >more.
    >
    >Jeff Jones
    >Marietta, GA


    Share on Google+

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center