Sponsored Link •
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:
It's primarily a people decision, not a technical one, even if technology has an influence.
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":
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.
|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.|