Porting or redisgn.

Computing Thoughts
Port or Redesign First?
by Bruce Eckel
July 23, 2007

Summary
I received a message asking about how to decide whether to port to a new language first, redesign first, or do both at the same time.

We have a large project that is coded in language A and has existed for many years. This project now requires a redesign and at the same time we would like to recode it in language B. From your experience, would it would better to port it from language A to B first, then work on the redesign, or code it in language B with the redesign from the beginning? The advantage with the first way is that we could possible offshore the porting, but I don’t know if the complexity of redesigning after the port would offset any gains in cost that offshoring would give us.

This is not a simple question because most of the answer is not about the accepted right thing to do, but more about “who are you?” The answer will be different from one team to the next.

You’ll have to reexamine all the code when you translate to a new language, and make changes to work within the new language idioms, which constitutes a redesign at least at a low level. This argues for doing it all at once.

But without knowing more about the project, taking baby steps is often a wiser choice. Most Agile processes can basically be summed up by saying “take a baby step and see what happens” (then, of course, automate that process so you don’t have to repeat all the steps by hand every time).

Some questions that must be answered before you can make your decision:

* What development process do you use now?
* Do you have unit testing, automated building and do you use version control?
* What condition is the project in? Is the design tolerable enough that you can “just change languages” or will you be forced to do some redesigns as you go?
* Is the existing design good enough that a third possibility, “Change Language + Refactor,” might be considered?
* How well do your people adapt to change? (This may be something that you can’t evaluate if you’re too close).
* What percentage of the people already have experience with the new language, and how much experience?
* What experience does your designer or design team have in (A) the new language, (B) this system and (C) this kind of transition.
* What constraints are there for this project: money, schedule, political climate, etc.?

It’s primarily a people decision, not a technical one, even if technology has an influence.
Offshoring

The fact that you’re considering offshoring suggests that you’re assuming something like “the existing application will work as a spec,” which may be true to a degree, but what will likely happen is that the offshore coders will do the simplest translation possible (using automatic translation tools if they are available), preserving all the idioms from the old language along with any coding quirks. These are easier and faster to just translate rather than analyzing; the offshore programmer is probably going to be very risk-averse and will not chance making changes to meaning.

So there’s some benefit in using offshore programmers, but now you will have a codebase that’s filled with idioms and quirks and any programmer who looks at it will be uncertain what those are about, and leave them in.

This also suggests the middle path, “Change Language + Refactor”:

Instead of paying an offshore company to use translation tools, do you have the infrastructure to just “sprint” it yourself?
If you don’t already have the unit tests in place, you will need them, and again the offshore programmers may not have the same incentives as you do so you can end up with subpar tests. You might be better off just using coverage-generation tools yourself.
Unless you know and have worked with the offshore programmers before, you won’t know what you’re getting and you might spend more time fixing the result than if you had done it yourself.

Note that approximately 50% of offshore projects are being canceled before completion (from a business magazine, I think it was Fast Company). The amount of effort required onshore is usually greatly underestimated. You’re basically just hiring more programmers, but you may not be vetting them yourself, they’re from a different culture and are on the other side of the world. I’ve worked with both Indians and Czechs in offshoring; both groups I worked with are very smart but both also required significant communication. The company that worked with Indian offshoring brought several of the key Indians to the US for months at a time, and I spent time in the Czech Republic. I’m not suggesting that offshoring isn’t a viable alternative, but that it can be a minefield that involves far more in time and effort than you imagine. Most of the successful offshore programs I’ve ever heard about involve more travel in both directions than you might expect.

So my answer to the whole question is that it’s really about understanding who you are as a company and a team, in order to discover the alternatives that might work best for you. There are far too many variables in this equation to be able to produce a single answer.

I suspect this topic will bring a lot of feedback from other readers, since many have had this experience.
Talk Back!

Have an opinion? Readers have already posted 10 comments about this weblog entry. Why not add yours?
RSS Feed

If you’d like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.
DiggDigg | del.icio.usdel.icio.us | RedditReddit
About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He’s given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.