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

Logic check

[greywar]

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.

Resume

[pete-classic]

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

Don't

[AuMatar]

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.

What is your current application environment?

[batkiwi]

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.

Re:Java

[Joe The Dragon]

You are being outsourced

General Thoughts

[AKAImBatman]

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.

Don't re-write anything!

[GoSmalltalk]

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.

A bit tangential

[JanneM]

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.

Oh my.

[Jerf]

Or conversely: what do we lose by moving away from C++?

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.

1. 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.
2. 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.

Process != Language

[bssteph]

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

Re:Don't

[AKAImBatman]

You have working code in C++.

Actually, he said that it's *not* "working" per se. He already stated that it's difficult to manage, and (I presume) full of bugs. This is a common issue for companies, especially if the original developers didn't fully understand the dynamics of the concept when they first coded it. (I believe the military saying is, "No plan survives contact with the enemy.")

In those cases it can make a lot of sense to do a ground up redesign and rewrite. You can still use the original code as a reference, as well as grab useful code snippets. But the key is to shake out all the cruft that has built up in the system. Without this sort of step, your development staff will simply need to grow and grow. Before you know it, you'll have 200+ programmers, and your company will look like SAP's development floor.

As for moving to Java, that's difficult to say without knowing their specific problem. If they, for example, have their own Web Application Framework, they might save huge amounts of development time and money by moving to a more standard platform. If there's nothing they can pare down, then they're probably wasting their time. It's hard to say without knowing more.

business cost of finding more developers

[coyote-san]

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.

Which "C++"?

[neutralstone]

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 [tinyurl.com]

http://tinyurl.com/ru625 [tinyurl.com]

http://tinyurl.com/mrdgo [tinyurl.com]

http://tinyurl.com/ounbe [tinyurl.com]

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

Re:Don't

[Marillion]

Initially, I'm inclined to agree. Swapping out a language to fix problems isn't fixing the problem. It's like those companies that move all the boxes the org-chart every so often trying to solve the problems of their company - those boxes at the top. The problem is poor development processes.

There are two kinds of Software Development Processes: 1) Manager centric and 2) Developer centric.

All the stuff we do at our company for Sarbanes-Oxley is classic Manager Centric SDP. It's about tracking the track every inch of code, who changed what, who had business authorization to put it in. Developers loose productivity over this, it's tedious, it doesn't improve quality, it doesn't prevent errors, but it does keep the auditors happy which does keep management happy.

The SDP's that benefits developers are things like Agile Programming. Among the cornerstones of Agile are Test Driven Development and frequent iterations. These are the processes that focus on preventing bugs in the first place.

I once worked for A Company [slashdot.org] that wanted all of #1 and none of #2. They got what the deserved. You need a measure of both with a dash of flexibility.

Software development processes have almost nothing to do with the choice of language. That said, it's been my observation that there are lots of really smart people working on Java to improve the development process. Eclipse is amazing with code completion, on-the-fly error tracking and refactoring. JUnit (comes with eclipse) is a benchmark Test Driven Development system. If you must switch languages, invest in the training to make those tools productive!

Java Spring and Hibernate are great, but...

[Anonymous Coward]

...That doesn't justify moving from your existing platform to Java. It sounds to me like the problems are your in your management and process, not your platform. If you can at least implement improvements in your process (tighter testing, then re-factoring) you could spend your time improving your existing codebase instead of trying to move all of that logic to a new paltform.

As for the off-shoring, if your management thinks it is a good idea, it's time to find a new manager. They have to be looking at it as a purely cost-saving solution and are not considering the hidden costs of trying to work with people half way around the world. Many companies are discovering that off-shoring is too expensive to do half-way; you either farm to whole project out to India, or you do it all in-house and add contractors as needed. Anything else can easily get to be more hassle than it is worth.

For comparison, I have been working almost exclusively with Java for most of it's life, and have really enjoyed using Spring and Hibernate, which both add a lot to the Java platform. That said, I can't think of any reason why I would have faith in a decision to abandon one platform for another after six years in the name of efficiency. That is the kind of decision that could only come out of poorly-informed management.

If I were you, I'd start looking for a new manager or a new job.

Re:Logic check

[Threni]

> Consultants who are familiar with jave recomend changing to java.

Why not find some consultants who like C++?

Re:Don't

[foobarbaz]

> But the key is to shake out all the cruft that has built up in the system. Every little bit of cruft is a bugfix that you'll have to make again.

Re:Don't

[Anonymous Coward]

>You have working code in C++.

Actually, he said that it's *not* "working" per se.


It's working a hell of a lot better than the java code that hasn't been written yet.

Re:Don't

[Anonymous Coward]

In those cases it can make a lot of sense to do a ground up redesign and rewrite.

No, it doesn't. While you're doing the rewrite, you have no product to sell, unless you maintain the old version in parallel. After the redesign phase, you'll find that the new version is buggy and incomplete, after all it's a new programm. When it is finally ready for premiere, you'll find that meanwhile the competition has driven you out of the market and that you developed a bad case of second system effect. The new system will have none of the old bugs, but a lot of new ones. Additionally it will usually eat more resources to do not-quite-the-same thing as the old one.

Never, never throw away you only asset, the program. Refactor it while keeping it alive, but never throw it away.

stay on target!

[abes]

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.

Re:Resume

[Ozwald]

This is a common tactic by consulting companies. It always follows the same flow, never fail:

1) consulting company hires a lot of junior/intermediate coders for his company that only learned Java or C#. C++ skills and experience avoided in favor of knowing the latest .NET/Java technologies.
2) an expensive consultant comes in to analyze an imperfect system
3) this person makes all kinds of suggestions, says nice things about management, says "use lots of UML"
4) says his devs are really good C++
5) brings in his coders to help fix bugs, charges lots of money for diagrams never used
6) consultant coders fail at fixing bugs, claim that code base is too fubar'ed to maintain
7) convince management to "port" code to Java/C#.
8) consultant coders soon have more knowledge of the system than the old devs because knowledge isn't shared properly (no more UML)
9) management becomes too afraid to let go consultant coders because they know more about the system than the devs (despite costing atleast twice as much)

I can't count how many times I've seen this because the city I used to live in had atleast 2 massive consulting companies that made this their business model. I imagine it's even worse when it goes off shore to India because all the knowledge is looked away in peoples' minds thousands of miles away. Such a huge mistake for management to lose all they paid for for nothing.

Oz

This is rediculous

[GorillaTest]

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"

Re:Hypothetical question:

[QRDeNameland]

GP>>>>Never rewrite working code.

What if:

1. The "working code" is several kB of sparsely documented assembly for a completely different (and old) CPU.

Then it's not really "working", at least not in the environment you need it to.

2. The people who wrote it have long since left the company.

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.

3. The "working code" was obviously designed, written and debugged over period of several years by several people, while you have six months to come up with a new working solution on your own ?

Then you have already ignored the "Never rewrite working code" advice in the first place. Good luck.