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."
Send the IT director on a one way trip to Basra
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?
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.
If you ARE writing web applications, then I would guess that moving to spring and hibernate from a completely from scratch c++ framework will result in much shorter development times. Serverside is where Java really shines in both performance and in ease of development.
Either way, we need more details.
You are being outsourced
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
Hi:
Re-writing your codebase is *usually* a one-way trip to bankruptcy. If forced to change languages, always dicey, you might want to try the following:
1. Mine the code so you have documented interfaces
2. Create wrappers where neccessary to facilitate access by *new* code
3. Write new functionality/apps in the new language
4. As your apps force change of the wrapped-code, evaluate the cost-effectiveness of a re-write of that piece only
And, most-importantly, use Test-Driven Development; you must mitigate the huge risk that your management has mandated.
Good Luck, you have your work cut-out for you.
Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk. My amp goes to eleven.
Joseph Bacanskas [|] --- I use Smalltalk. My amp goes to eleven.
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.
Give the team a lobotomy. That'll do it!
Buckle your ROFL belt, we're in for some LOLs.
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).
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)
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.
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.
Anything is possible, except skiing through revolving doors.
Something overlooked in the trenches is that there's a very good business reason for switching from legacy C++ to solid Java (spring/struts/hibernate).
Finding employees.
Not because of "oh, I'm too good for C++" jerks. Just the simple fact that most recent development has been in Java, not C++. (C is also increasingly hard to find.) That's important when you're looking to expand your staff or replace departures -- it's harder to find people who are current in C++, and harder still to find good people who stayed with C++ instead of migrating to Java.
Same thing with using standard packages like Spring and Hibernate. They may not be the best technology, but they're almost always good enough and you can find good people who know how to use them.
As for outsourcing... huge mistake with a project this small. Besides the nightmare of managing a small team in a distant timezone, development teams this small need a lot of soft skills specific to the deployed environment. You could get around that with a rock solid spec, but I doubt that's the case here.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Are you talking about Standard C++ or Microsoft++? There's a considerable difference, especially in recent years.
Microsoft likes to present a lot of its own extensions as "C++" features. In particular, they like to present C++/CLI (a.k.a "CLI++") keywords as "C++" keywords.
And then there are the managed extensions. (But even Microsoft has deprecated those in favor of CLI++.)
Going back even further, there's MSVC 6. Lots of people still use it, but it's just too old for anyone to expect it to be close to Standard compliance.
What compilers do you work with? Do you set compiler options to disable extensions and run in a "strict" standard-conforming mode? Do you use more than one compiler?
Do you make judicious use of the STL? Do you use any part of Boost? (If not, you should seriously consider taking some time to learn about these best-of-breed libraries that are available *for free* and for which support is available from multiple consulting firms.)
Did you give up trying either of those libraries before trying out STLFilt? (If so, go play with it. You'll probably want to give generic programming a second try.)
Have you and your team read any of the *good* C++ books? E.g.:
http://tinyurl.com/puhjb
http://tinyurl.com/ru625
http://tinyurl.com/mrdgo
http://tinyurl.com/ounbe
Have you invested in static analysis tools? (E.g., PC-Lint, etc.)
Most of the C++ programmers who cut their teeth on Windows learned a watered-down version of the language by way of the Microsoft libraries (e.g., MFC, which should *not* be mistaken for a model of modern C++ interface design). If that describes most of the people on your team, you should seriously consider migrating from "kinda-C++" to Standard C++.
"Things you should never do, Part 1": http://www.joelonsoftware.com/articles/fog00000000 69.html
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/). 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/) 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/, wyoFiler http://freshmeat.net/projects/wyoeditor/) 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
See http://wyoguide.sf.net/papers/Cross-platform.html
From somebody that DID do C & C++ and has been doing mostly Java for a number of years now:
- Get an experienced Java Developer/Designer/Architect inhouse at least for preparing and doing the migration. Put that person in a team-lead/team-coach role or at the very least use him/her for high-level design and for code reviewings. No mater how good you guys are, when you move to a different language AND more importantly a new set of libraries and frameworks, if you do it on your own you're going to make all the mistakes a "new guy" does which means a lot of going back and forward as you figure out that your initial design doesn't quite work with Hibernate/Spring/J2EE/whatever.
- Develop a couple of some small apps first, just to get some experience with the language itself - take a week or two doing it. Try and use the libraries/frameworks you wanna use in the main project - for example, if you wanna use Hibernate to access the database, do a small app that works with it.
- If some of you guys are still using non-object oriented features from the C side of C++, you're going to have problems moving to Java. The simplest solution is using loads of static methods in an auxiliary class. DON'T! Generic auxiliary methods in Java are the exception, not the rule in most applications.
- Beware of thread safety. Multi-threading is a built-in feature in the standard Java libraries, and when using some of the major frameworks (J2EE for example, both the web side and EJBs) or having to deal with asynchronous events from multiple external entities (for example the server-side of a multiple-user client-server app) it is almost guarante that some of your methods WILL BE called by multiple threads simultaneously. If you make auxiliary methods at the class level (or worse, in a generic class), beware of them keeping state - in a multi-threaded environment there is no guarantee that said methods will be called in any given order, even if the your code looks like it will never do otherwise. The only way to control multi-threaded access to resources that have state is to either not share them (ie put the auxiliary methods in an object or encapsulate state in an object that gets passed to the methods) or carefully using synchronized blocks and methods (very few people know how to do the last one properly). Fortunatly, good OO encapsulation avoids most problems with multithreding.
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.
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.
Stupid job ads, weird spam, occasional insight at
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.
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
Well, to agree with just about everyone else here, for the whole team to learn Java, get used it its quirks, etc. is going to take a good amount of time. One thing that it does sound like, is that there is a library issue -- your current library is unmaintainable, and perhaps the ones Java provides takes care of that. Maybe that can cover for the time it takes to learn Java (since it's based on C++, it's not so difficult, but at least last time I checked, it lacks many features that you'll have gotten used to in C++).
Main sticking points (since it's been years since I've last used Java, someone will probably have to correct this):
* lack of templates
* lack of double inheritence
* everything is a pointer (both good and bad)
* you have to be aware of garbage collector for optimizations
* more verbose: both libraries are verbose in nature, and syntax can be a bit more verbose
I think most issues people have with C++ can be solved with the right library. Want garbage collection, use a garbage collection library. Or use the STL (check out boost too!), which has just about all the container classes you could possibly want or need. Roguewave has also always provided a good amount of commercial quality C++ libraries. And don't forget QT. Way way way better than any interface provided by Java. I'm not a big fan of Swing (or AWT) at all.
If you want to talk in terms of productivity, one method of sticking with C++ (although it sounds maybe the decision was made already) is to use a hybrid (come on, everyone else is doing it!). I use the boost::python library a whole lot (though there is SWIG, Weave and Pyrex as well). All my optimized code stays in C++, and everything else is in Python. I know Python isn't the fastest language in the world, but I don't have to worry about that. If I need to read in a configuration file, write a quick XML parser, etc. -- easily done in Python.
Python is far from a perfect language -- I get bitten by the whitespace issue quite a bit (yes, if you stick with one editor it's fine, but you might always have that luxary, and some editors insist on using tabs). It is definitely one of the more complete interpreted languages with a huge amount of libraries written for it. Also boost::python, like all template library will slow your compile down by a lot. On the other hand, you compile your code less, since most of your work is in Python. And Python takes 1 day to learn.
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.
--- These are not words: wierd, genious, rediculous
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.).
"Avoid employing unlucky people - throw half of the pile of CVs in the bin without reading them." -- David Brent
Why do people always need to pick a dramatic solution? Just take some time out to refactor your code. That will be a lot cheaper and more effective than going through this exercise your IT chief has planned. I've gotta ask why are you putting up with this headache to begin with. Go somewhere where they unit test so refactoring is practical, and where the big chiefs are not allowed to read "Development for Dummies"
Then it's not really "working", at least not in the environment you need it to.
Unless it's written in such an obscure language that you can't find anyone to maintain it, you're probably still better off hiring someone to try to get a handle on your existing code than to make someone reimplement from scratch. Plus if the only people who know anything about your code are long gone, then the code must not have needed much maintenance anyway.
Then you have already ignored the "Never rewrite working code" advice in the first place. Good luck.
Momentarily, the need for the construction of new light will no longer exist.