Porting [insert_language_of_choice] to .NET
I am in the office not 10 minutes this AM, and I am called over to my neighbor’s cube where a couple of my teammates ask me, “how difficult is it to convert PHP to .NET?” Being the only developer on the team, I give the standard “safe” answer, “that depends…” I followed up with a comment saying I hope they (our vendor) did not rely on a tool to do the job, but of course, they did.
Vendors are like anything else in this world—you get what you pay for. There are scenarios where the use of a tool *may* be warranted, however the majority of the time simply porting the application manually—rewriting the code by hand—is the smartest way to go. In fact, to put your code into the hands of a black box tool to do the conversion work for you is not only risky, it’s stupid. The word that comes to mind is amateur.
Regardless of how you do it, you still have to put eyeballs on the code, doing a thorough review even if the business logic did not change; the code did change. My experience has been that conversion tools incur a greater hit in time and resources compared to doing the conversion by hand. By hand-rolling the conversion code, it also forces you (or provides the opportunity) to know and understand the converted code at a level of familiarity that allows you to navigate and debug the code intuitively.
Granted, there are vendors out there that I am sure have high quality products that do this type of work for you, however they are just that—tools, which are not meant to replace the process altogether. Unfortunately, this seems to be the mentality of many out there, marked by laziness, not to be confused with the “Big-L” Lazy coder works smarter vs. the generally lazy coder that is just that—too lazy, or is unqualified to do the job in the first place.