Forgot your password?
typodupeerror

Moving a Development Team from C++ to Java? 204

Posted by Cliff
from the language-defection dept.
Nicros asks: "I work for a company that is working toward an FDA approved software development process. We have always used C++ in a Windows environment, and we have more than 6 years of code, applications and libraries developed. Because of our long and convoluted software development history, our existing architecture is difficult to manage for a group of our relatively small size (5 FTEs), and development times are rather slow. Our IT director has made the decision that, to speed up development times, we need to re-architect all of our existing code, from C++ to Java." What would be the best way to go about handling such a migration? In a general sense, how would you go about moving a development team from one language to another?
"Our IT director has hired a 3rd party (offshore) company assist us with this migration, and they have recommended that we change from C++ to Java, Spring and Hibernate. We are all professional programmers here, so learning Java is not a problem for those of us who don't know it. The real question is: what do we gain from moving to Java? Or conversely: what do we lose by moving away from C++? Additionally, will one language or another really help us to get FDA approval?

I personally am a bit suspicious of this solution. I find it more likely that the problems we have would persist across languages or architectures (lack of time and resources leading to buggy code, lack of direction from marketing, and so on). However, having not gone through this process before, I would be interested to hear any thoughts, stories of similar experiences, or pros and cons."
This discussion has been archived. No new comments can be posted.

Moving a Development Team from C++ to Java?

Comments Filter:
  • Re:Logic check (Score:5, Interesting)

    by dhasenan (758719) on Wednesday May 17, 2006 @10:06PM (#15355625)
    Agreed. You might see benefits if you start using a language that interfaces well with C++, though--perhaps Python? That would allow you to keep your existing work and continue using C++ while exploring more platform-independent and possibly quicker systems for development.

    Switching suddenly to Java, though, is a bad idea if you don't already have the expertise.
  • by MikeRT (947531) on Wednesday May 17, 2006 @10:36PM (#15355755) Homepage
    J2EE before things like EJB 3.0 is pure crap. Convoluted, difficult to grasp crap. Research the lightweight frameworks and give them a shot first. They're much more straight-forward and Javaesque than old J2EE. Java was supposed to be a simplified C++, but older J2EE actually made it quite complicated, and really unnecessarily so.

    I'm not trying to troll, as I actually like Java and think it's a solid language. I'm just not going to lie to you and say that the JCP people were sobre when writing up the older J2EE specs.
  • Why change? (Score:3, Interesting)

    by Fred Nerk (128328) * on Wednesday May 17, 2006 @10:36PM (#15355756)
    My professional advice would be to stick with what you've got. If it's 6 years worth of C++ code, it's probably going to take roughly that amount of time to get to the same place with Java.

    It'll be slightly quicker because you already know what you have to duplicate, but more than likely you will go through the same bugs and teething problems that were already solved years ago all over again.

    If you get this offshore company to redevelop in Java, they are going to hand you a pile of code which you don't understand (because you're all used to C++), and don't have any stake in. Your developers are going to be less interested in fixing other people's bugs than their own (that's my experience anyway).

    I think you'd be better off spending the money to hire some local contractors to cut down your codebase. Keep the language and functionality the same, but any project which has grown over 6 years is going to have crud that can be removed or rewritten. Spend your time imroving what you've got rather than starting again.

    Also my experience of one offshore dev company was that they cut & pasted some open source (GPL) code, changed a few lines then tried to charge me for 3 months of development work.
  • by danpat (119101) on Wednesday May 17, 2006 @10:47PM (#15355805) Homepage
    "Things you should never do, Part 1": http://www.joelonsoftware.com/articles/fog00000000 69.html [joelonsoftware.com]
  • by Anonymous Coward on Wednesday May 17, 2006 @10:56PM (#15355843)
    Yep. I used to hate working with Java several years ago because of EJBs and confusing, impenetrable frameworks with dozens of XML files. I've since looked again at Java. Things have improved.
  • by wysiwia (932559) on Thursday May 18, 2006 @05:10AM (#15355948) Homepage
    As others have already asked, what environment you currently use is critical for any development strategy. Simply switching from C++ to Java will gain you nothing, what counts is what better framework you want to use. Since you only mentioned Windows I guess you just use plain MFC but since you also mentioned Java I guess you need to divert to a cross-platform solution.

    In case your future environment has to produce binary applications you are IMHO best of if you switch to the wxWidgets framework (http://www.wxwidgets.org/ [wxwidgets.org]). Since you already have C++ knowledge and wxWidgets is quite easy for Windows developer it shouldn't be a big problem to become familiar. I'm quite sure with wxWidgets you are equally efficient as with any Java framework but don't have the disavantages of Java.

    You can use wxWidgets regardless of any platform consideration, if you just want to stick to Windows or to Linux or whatever, it doesn't matter. But if you also follow the guidelines of wyoGuide (http://wyoguide.sf.net/ [sf.net]) you can move your code anytime to another supported platform and just release it. As long as you just use the features of wxWidgets there's no need to recode anything on other platforms ever.

    If you want to see how well this approach works try out my samples (wyoEditor http://freshmeat.net/projects/wyoeditor/ [freshmeat.net], wyoFiler http://freshmeat.net/projects/wyoeditor/ [freshmeat.net]) or look into Audacity. Or look out for the commercial application Xara. There's probably no alternatives for cross-platform development as if you do single-platform development as with wxWidgets/wyoGuide. And keep in mind, no Java disadvantages.

    O. Wyss
  • by Lumpish Scholar (17107) on Thursday May 18, 2006 @08:10AM (#15356506) Homepage Journal
    ... only to do even worse this time?

    Seriously, that trick (pretty much) never works. I remember one project where six developers in a row said, "This code is unmaintainable, it needs to be rewritten from scratch." Think about it: it was rewritten from scratch five times, and each time, the result was still so bad that the next maintainer gave up on it.

    Here are some questions for the IT director's boss: When has this director done something like before? How successful was it the previous time(s)? What mistakes were made in those cases that you can learn from this time around? What mistakes were made in the development of your current system that you can learn from this time around?

    (Are you risking your job by going over the IT director's head? News flash: your job is already at risk.)

    You guys are about to be squeezed seven ways from Sunday.
    • The IT director is counting on offshore outsourcing to replace the system; it's probably planned as a one-way trip, and (if successful) likely to go that way even if that's not the plan. (The director's job is as likely to be relocated as yours is.)
    • The offshore guys are calling the technology shots, for their convenience, not your benefit.
    • Worst of all, the director has given up on maintaining the software; if someone can't manage maintenance, they probably can't manage a major greenfield development project, either.

    You're probably psyched about getting to learn new technology. Well, get psyched about this: odds are, the project will fail, the IT director will be fired, his or her successor may be even worse, and you guys will not be fired, but instead will still be left trying to clean up the mess you currently have.

    Fight it; you have nothing to lose but a job that's about to get a lot worse.
  • Been there done that (Score:3, Interesting)

    by SysKoll (48967) on Thursday May 18, 2006 @08:50AM (#15356645)
    I used to work in the Software Group of a large (large!) company that had developed its flagship application server mostly in C++, starting from the late 90s. We had a huge bugginess and productivity problem. The bug fixes were coming too slow and we had persistent quality issues. Furthermore, we could not port our C++ code to the umpteen platforms that marketing wanted to target.

    In 2000, we made the decision to move to Java. Moving to Java was painful at first. We managed to introduce new Java code while reusing the old C++ parts for a while, but we finally rewrote everything in Java. The Eclipse IDE boosted our productivity considerably, and the product is very successful. So I guess it makes sense.

  • Dear god, no. (Score:3, Interesting)

    by MythMoth (73648) on Thursday May 18, 2006 @09:46AM (#15356943) Homepage
    I'm a full time Java consultant who used to be a full time C++ consultant. I like the Spring framework, and I've written a book on Hibernate. And I think this idea is just insane.

    Take your existing system and build upon it incrementally. If it is full of bugs, replace the buggy components incrementally. If you can't figure out how to maintain it in this incremental manner, I guarantee that the big-bang solution is going to be a total disaster anyway.

    And this is all setting aside my reservations about the wisdom of outsourcing a project like yours.

    Good luck. You are going to need a lot of it.
  • by lorcha (464930) on Thursday May 18, 2006 @10:25AM (#15357207)
    Just because you fail to understand it, doesn't mean it's crap. The following are not crap, and were never crap: JMS, JMX, JNDI, MDB, Session EJBs, CMT, JSP, JAAS, and many others.

    Really, the only part of J2EE that I can think of that was ever crap would have to be Entity EJBs (high overhead, high complexity, too expensive for simple DB access, too difficult to get complex queries to behave (BMP), required meaningless conversions due to nonserializability, etc., etc.).

  • Re:Oh my. (Score:4, Interesting)

    by 0xABADC0DA (867955) on Thursday May 18, 2006 @12:23PM (#15358170)
    Six years of C++ development, and all the corresponding skill development. ... That's a shitload of stuff to just throw away to be buzzword compliant. ... The key word is incremental. Incremental might succeed.

    Let me be the lone voice to call bullshit. Story poster is obviously inexperienced and trying to be diplomatic (if for no other reason than pride). What we have here is almost certainly a big steaming pile of crap.

    Their development has slowed to the point where they are going to ditch the whole thing. It's too late to save this code. Putting a nice interface on it will just exacerbate the problem because anything you try to do will either expose the underlying crap and bugs (ie mfc, .net forms) or be as much work as a re-write.

    Just take a look at Windows for an example of what happens when you try to incrementally evolve something like this: 6 years with basically no innovation because updating anything is so slow and difficult. Meanwhile both Apple and Linux have made leaps and bounds, Apple by ditching their massive investment in OS 9 and Linux by shunning backwards compatibility. Linux doesn't have binary kernel drivers because mapping better stuff to old mistakes is even harder than keeping a zillion drivers up-to-date. I'm always getting "kernel too old" messages trying to make binaries that run everywhere. It sucks, but imho it's a huge reason why Linux is advancing instead of stagnating. The only reason Microsoft is still around is because of lock-in; if poster's company doesn't have a lock on the market and given their codebase they will fail if taking the incremental approach.

    I think it's painfully obvious that whatever it is they are doing (I'm guessing some database + COBRA junk) is something that shouldn't be written in C++ in the first place. For example, poster does not mention performance at all. C++ *can* be a lot faster than Java at some things and is a pretty good choice for those (action games for instance), but if you are not even slightly concerned about it then that's a pretty big tell that using C++ for it is a huge mistake. Ideally they would write most of their code in Python or Ruby or similar, but it sounds like this could be out because of client issues. So Java or C# is probably the only realistic language to code in.

No amount of genius can overcome a preoccupation with detail.

Working...