There's never time enough to do it right the first time, but there's always time to do it over again, or so the old adage goes.

The last couple of projects I've worked on have ended up including the rewriting of the code in another language after the initial launch. In one case it was for performance reasons. In another case it was because the bulk of the company's code was in a particular language, but it was quicker and easier to do from scratch using a different language.

In today's "just get it out there" culture, we often seem to make design decisions based on short-term expediency in order to get a product out the door, while failing to consider the longer term ramifications. This often leads to substantial lost productivity both in trying to diagnose and patch problems, and then rewriting the code where necessary. Sometimes, this can also lead to pain for the users.

For example, Twitter's scaling issues and potential problems with the Ruby on Rails framework are well known. While Ruby on Rails is exceptional when it comes to building Web tools quickly, Twitter is a victim of its own tremendous success, as they clearly didn't plan for the kind of scaling they now require. They are apparently considering rewriting portions of the code to improve performance.

The folks at reddit transformed their site from Lisp to Python, resulting in less code that ran faster and was far easier to read and maintain.

Of course there is a possible upside to rewriting your code that I've often noticed. When you go through your code for the second time you always get to improve it, cleaning up the messy stuff you put in the first time just to get it to work, and you get to clean up the performance issues you've already seen.

My last project had a very messy piece of JavaScript code that passed arrays back and forth with a piece of PHP code, in order to allow the Web page to be rewritten on the fly. When I rewrote the PHP code using Java Server Pages (JSP) instead, I was able to clean up the JavaScript substantially, improving the performance and making it easier to support in the future. Which is wonderful, but it extended the time and cost of the project by about 50% over the time and cost of doing it right the first time.

But when do you stop rewriting the code? Neil Gunton calls this "Rewrite Mania" -- the tendency of engineers to always want to make things better. Sometimes good is good enough. Rewriting code also has the bothersome side effect of introducing new and unexpected bugs.

It just makes good sense, both time-wise and economically, to clearly plan your requirements, choose your language and database, then build a system that is scalable -- once -- and get it right, or as close as you can, the first time. Ensure that it is built in the same language as the rest of your tools if appropriate, and that it works with everything else you use.

Concentrating only on "just getting it out there" is rarely a good idea if you plan on being around for a while. Spending some time upfront to get it right pays off in the long run.

Larry Borsato has been a software developer, marketer, consultant, public speaker, and entrepreneur, among other things. For more of his unpredictable, yet often entertaining thoughts you can read his blog at larryborsato.com.