CincomSmalltalkWiki: Why would you move from Smalltalk to something else

Why would you port an application from Smalltalk? Ports of this nature simply don't make business sense. Think about it -

let's assume that the port takes N months to complete
The port will include no new functionality
The port goes flawlessly

This is the best case. In that case, you have utterly wasted N * M (where M is the number of people involved) person months. Those months produced no new value, nothing that would help you in your actual line of business.

Now let's take the likely result - since Language A and Language B are different, the port won't be a port - it will be a re-write, mostly from scratch. Why? Because the implementation you have relies in many ways on the strengths (and weaknesses, to be fair) of Language A. When your staff attempts to recreate the application in Language B, they will invariably write in the style used in Language A. Thus, you'll end up with an application that is (relative to the strengths of Language B) poorly written.

So what if we have a new team do the work? In that case, you get to leverage none of the domain knowledge of the staff that first created the application. So you can assume that doing the port will take (at least) as long as it took to write the initial application in the first place.

Given all this, where's the business value in a port? Can your business afford to take a full stop during the time it takes to re-write? Or would you be better off moving forward with new functionality that might help you grow the business?

Finally, let's assume that the origination language is Smalltalk, and the destination language is Java. From a function point analysis standpoint (See: SPR Research), it takes more than double the amount of Java code to produce the same results as one can get in Smalltalk. It takes physical time to produce that code, and if there's more of it, it will take more time. More code also means more bugs; your initial port will have more bugs than the application it replaces. The tools for producing the Java application are also primitive when compared to those available for Smalltalk - the source code management systems, the development environment, the debugging tools - all are inferior in the Java world. This again will slow down the production of the port.

In the end, what is the goal of the port, as opposed to the goals of the business? What business value will be achieved by spending a lot of time standing in place as opposed to moving forward?

On the other hand, if it isn't a direct port, but will have added functionality, it may be beneficial to re-write in a more efficient language (such as Smalltalk!).