What if you used the wrong language?

Question

A reply to another question made me remember a project from some years ago when it turned out that Java was not the right tool to use.

I typically only learn a new language when I have a problem that it solves better than the ones I already know. [...]

Then I write whatever program I wanted to learn that language for in the first place. [...] By the time I've gotten my target program written, I've usually got a decent handle on the language, not to mention any other features it has, and I've got other ideas to use it for.

I did just that back then with Java, because the client thought it to be the right language to use (platform independent) and initial evaluation confirmed that.

However, much later in the project there were some issue (can't really remember all the details by now). So, the project that started as a nice learning experience turned into a nightmare toward the end.

I was at the brink of switching over to my trusted C++ and doing a complete rewrite. The client was not so much of a problem to convince back then, but my supervisor was strongly opposed because of all the work that already went into the Java version. In hindsight, he was right and the project was complete more or less with the intended features kind of working, but it was the project that I am least proud of by now.

Long story short: what do you think, when is it too much and the switch to another technology is worthwhile? I personally would estimate the point of no return to be around 50% of the planned effort, but really want to know, if anyone has real experience with such a switch.

And to answer the inevitable question: I do not really care, if the technology switched to is proven or another new thing. The latter would basically need more initial scrutiny based on the past experiences in the problematic project.

Answer 1

It depends on the switch.

I guess the formula would be:

int daysOnOld =  //days to finish the app in the original tech
int daysOnNew =  //days to finish the app in the proposed tech, 
                 // assuming the switch has already happened

int daysGained = daysOnNew - daysOnOld;
                 //days gained over old tech implementing 
                 //the rest of the app in new tech

int daysLost =   //time lost switching from old tech to new tect

bool shouldDoIt = ( daysGained - daysLost ) > 0

The problem is that even moving from a 'difficult' language (say LolCode) to a really 'easy' one (both highly subjective) makes a relatively small proportional difference.

Basically your daysGained is always going to be relatively low.

I reckon the average cut-off is closer to 10% into the project.

Answer 2

In general, I would be inclined to say that if the language is capable of doing what you need it to do then it really isn't the wrong language for the job, it's just not the best language for the job. While this might sound a bit like arguing semantics, there is a different between trying to use a language like JavaScript to write a desktop application (wrong language for the job) and just picking a language that is not the best one to use for the job. For example, trying to write a First Person Shooter that gets 60+ Frames Per Second in BASIC, you might be able to do it, but it would be difficult to do.

As for when it makes to sense to re-write an application in a different language, I would say it makes sense only if there are no other options for implementing the code (e.g. existing library, making a call to code written in another language) and the time it would take to write the code in the current language is more than the time it would take to re-write the existing code.

Answer 3

Thanks for the input.

That explains the firm decision of my supervisor at the time.

Answer 4

@Keith

Don't forget about the ability to maintain and extend the application in the future. Even if switching would not produce a net gain on solving the immediate problem, it might be better to bite the bullet and switch before you get even more entrenched in the current codebase. Unless there is some really pressing need to get the product released now or it has a short expected lifespan, then going with the best long term solution will likely pay off.

Answer 5

@ricree

Good point.

Lucky for me, the project turned out to be shelved by the customer anyways, so it did not turn into a maintenance nightmare. There are other projects here that did turn into maintenance marathons despite using the right language (cough changing requirements cough), but that is another can of worms.

Answer 6

Have to say, it depends on how far you are and whether the client wants to pay quite a lot more for something great, or just a little bit more for something that is much as they see before them. A rewrite will be WAY better, mostly because you know how to design it properly, what tools to find, what to pay for.

Answer 7

Recently some colleagues of mine had a client remove some requirements after realizing that it cannot be done with the current embedded framework.

Starting more or less from scratch with another framework (and asking more money from the client) was out of the question.

Answer 8

Generally speaking, I think the best language for the job is the language you know best.

Of course, if the project has special requirements (like dynamic classloading or interfacing with the video card), then those requirements might narrow your range of choices.

But once you've narrowed the candidates, I think the main consideration should be the experience of the developers. If both C++ and Java are capable of meeting the requirements of the project, but the developers are more seasoned in C++, then I think the choice is easy.

From your description, it sounds like this was exactly the scenario you were in. Java was probably just as capable of meeting the project requirements, but based on your experience, the development process would have been much more smooth and painless if you had chosen C++ from the get-go.

Answer 9

A rewrite is usually a bad idea, see Joel's post on Things You Should Never Do.

That said, I'm a C++ developer myself and I would always prefer C++ over Java. But that's just my personal preference. I don't think that Java is a bad choice for most commercial projects. I wonder what issues there may have been that made you think a C++ rewrite would have been worthwhile..