Slashdot Mirror
Moving a Development Team from C++ to Java?
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."
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."
OK so you all have years of experience in c++, 6 years of code, etc. Consultants who are familiar with jave recomend changing to java. And changing development languages and re-doing all of this will save you time? I just don't buy that, to me it sounds more like it will make those offshore consultants more money. You're going to spend the next couple years re-writing all of your old work, not getting things done.
Sounds to me like the best case is that some salesman has convinced your management that Java is a cure-all. The worst case is that your management has decided that this is the first step in off-shoring your job.
In either case my advice to you is the same: Polish up your resume.
-Peter
You have working code in C++. Throwing out all that work will take years and millions of dollars. Even if Java doubled your productivity (it won't- you don't have experienced Java developers so it will greatly reduce your productivity) it would take over a decade to break even if you ever did.
Never rewrite working code. Refactor, rewrite subsystems if absolutely necessary. Otherwise leave it as is and if you really want to experiment with Java, do it with new tools.
I still have more fans than freaks. WTF is wrong with you people?
In general, rearchitecting a system can be a good way to update it for your current needs. The key however is to architect, not simply recode the exact same design. You need to see what your needs are in a system and decide what it is that you could meet if you could just change the basic approach.
In your specific case, however, I'm a bit concerned about the track your company has taken. My concerns are:
1. You're going to have a separate company working on your codebase when they have no intimate knowledge of how it *should* work.
2. No one in your team is an expert in Java. This is problematic because good Java code has a very different profile from good C++ code. (Mainly due to auto-optimizations and garbage collection.) Things that were good ideas in C++ may actually hurt you in Java.
3. Your lack of knowledge in Java is going to guarantee that Java's features won't be put to full use in the design. Which means that you may end up short of your maintainability goals.
4. Blindly accepting a framework is a recipe for disaster. Unless you clearly understand the framework you're working with, you will tend to try and fight it instead of working with it. This will result in a lot of unnecessary hacks.
My best suggestion for your company is to get a Java architect on staff who's also familiar with C++. (It's okay if he's a consultant as long as he's planning to be on-site for the next year or so.) Postpone the project for a few months while he gets up to speed on what your system does and what it needs to do. Once he's up to speed, he can work with the staff to develop an architecture that will meet the needs of your company and your platform. Use the outzourcing company for busy-work ONLY. Make sure that the API specs are well defined before you send ANYTHING to them for coding.
As for the FDA approval, rewriting isn't a magic wand. You need to ensure that their requirements are taken into account during the architectural design phase. Otherwise you may fail to meet the goals.
I'm not sure if your boss will agree to getting a highly paid Java architect to join your team OR to postponing the project, but thats the best advice I can give you. I presume if you already knew the answer you'd be championing it instead of asking us.
Good luck to you! I hope it works out.
Javascript + Nintendo DSi = DSiCade
A tangential comment: You say a large part of your problem is a convoluted, complex architecture that's been growing for some years. That happens - in fact, it's probably inevitable to some extent, whenever you have a codebase that needs to change as requirements and use-cases do.
And to solve that problem, doing a redesign and rewrite (or a close analogue) is probably a good idea, no matter what language you'd be doing it in. You need to get rid of all cruft, strange corner cases and mismatches between the envisioned architecture and the reality. Look at any large, well established OSS project and you'll see that they've done that too, sometimes more than once. And if you're going to rebuild from the ground up, more or less, you might as well take advantage of the better tools that's become available as well. And from C++, any of the newer development languages - whether Java, C# or even Perl/Python/Ruby - would probably be a step up in development speed and maintainability.
Of course, OSS projects are also a showcase for how wrong it can go. You do need ample time and resources to do it - a rush job will just make the new system as bad as the old one, but with all-new problems in addition to the old ones. You also need serious constraints. Without them you'll inevitably succumb to feature creep ("wouldn't it be nice if we could..."), which will kill the system just as surely as a crappy reimplementation would.
For every OSS project out there who did a redesign and rewrite and came out stronger, faster and better for it, there is a project that started a redesign just to get rid of cruft, went off into the design neverland and never appeared again, suicided by the endless opportunities that rewrite gave them.
I think the use of Java is beside the point. The opportunities and pitfalls lie with the redesign and reimplementation. The tools are just an implementation detail.
Trust the Computer. The Computer is your friend.
Six years of C++ development, and all the corresponding skill development.
Even with the C++ to guide you, and assuming you had all the manpower to do the full conversion to Java that you had to write the C++ in the first place, you'll need at least a third of that time again to re-write the whole thing in Java, most likely. And that's being conservative; if you're good with C++ it's extremely likely to borderline-certain that you have used idioms that will translate poorly or effectively not translate at all into Java.
That's a shitload of stuff to just throw away to be buzzword compliant.
My suggestions would be to do one of two things.
- Research JNI and see if that would allow you to incrementally pull things over to Java as you need them, while leaving the rest C++. C++ is so wonderfully... ahh... I'll go with "powerful" that it's hard to tell how things will interact, but if you can pull things over incrementally, you can at least not toss everything all at once. Because that's a guaranteed recipe for disaster.
- Research your choice of Python or Ruby. My recommendation would be the former as it's more mature in a lot of little ways (and some big ones, like Unicode from what I hear). There are several technologies for using C++ objects in Python. I presume there are some in Ruby. Incrementally wrap pieces of your code in Python handlers as you need them, write Python or C++ as the situation warrents. There are other such languages to consider too; you'll have to evaluate them for your needs.
The key word here is not Java or JNI or Ruby or Python; those are really incidental to my point. The key word is incremental. Incremental might succeed. Attempting Total Switchover is just writing a check to the consultants for no return this decade.And while you're incremental-ing and maybe wrapping, be sure to write unit tests if you haven't already got them. If you do manage to not toss out your entire code base, a good first step for any of this is to write unit tests on the parts of the code you're going to manhandle.
You say you're looking to achieve a "FDA approved software development process." And your IT director decided that Java is the magic bullet.
This should be setting off some kind of warning in your head.
A software development _process_ has little to do with implementation language. What you're looking for is a way to verify that you and the rest of your developers can rigorously apply software engineering principles in your organization and (reasonably) predict cost, development times, etc.
You should have your developers reading the Capability Maturity Model, not books on Java. The government loves the CMM. I'd suspect a critical organization like the FDA would want CMM Level 5 (as hardcore in software engineering as you can get) out of your _organization_.
That is, the process is people, not implementation language. Java being the green light is a load of malarkey (or at least, it should be).
Since you mention Spring, I'm guessing that you're writing web applications. If you're not, then you need to tell your manager to jump off a bridge, as he has no idea what he's talking about.
I disagree- containers like Spring are useful for all sorts of applications, not just web-based ones. Stitching components together via configuration files, combined with aspects and "inversion of control" makes it a lot easier to build maintainable and extensible applications. There's nothing in the core Spring framework that shoehorns you into writing web apps.
That being said, the OP should probably stick with C++, unless there are much more compelling reasons than "the offshore consultants said to use Java, Spring, and Hibernate".
Before you go and hire a bunch of off-shore'ers you need to hire an on-shore FDA compliance expert who can walk you through developing a CFR 21 Part 11 compliant development process. The funny thing about the FDA process is it doesn't recommend best practices rather it forces you to make a plan and stick to it (and document that). They want a paper trail should anything go wrong more than anything else, so problems can be indentified and fixed. You ought to do a bang-up job as well, for your company's competitiveness, but that's optional.
Expect to properly validate all your code with good test cases. This is probably a good thing for moving languages. Write a test case for the C++ code, validate that the C++ code works, implement the Java version, make sure the test case results are still the same. The JUnit tools might be helpful here, though I haven't used them personally.
Java gives you some advantages to write more robust code, especially among collaborators. But you can thwart that by doing try { } catch (Exception e) {} instead of catching the real exceptions. That's a matter of coding practices - you ought to mandate people catch actual exceptions thrown and call them girly-men if they don't. If you mandate it in your process they have to follow it or you won't be compliant.
I also find Bugzilla to be very helpful in an FDA-complaint process, using the VERIFIED status to mean 'validated'. CVS is really important, or probably Subversion today.
Over all you'll probably feel like you've done a better job as a software developer by using a good FDA-compliant process because bean counters can't force you to cut corners, though good work can be tedious. Beware they don't fool you into working crazy hours to make up for the additional workload.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
"Things you should never do, Part 1": http://www.joelonsoftware.com/articles/fog00000000 69.html