As developers, we’re usually forced to do each project with the tools we have on hand at the time development starts. But inevitably, new tools come along, and, as time goes on, the desire to switch to new languages and frameworks becomes stronger and stronger. With Microsoft releasing new versions of the .NET framework every 2-3 years, and Sun following a similar release schedule for Java versions, it’s easy to feel like you’re using obsolete languages and tools, even after only a couple of years. And of course, many people are still writing and maintaining desktop apps using the Win32 framework (which has already been wrapped with 2 frameworks, prior to .NET) or Carbon on Mac OS X. We face a similar situation when we look at database server software, as well, with new versions coming out at a fairly steady pace (and often incorporating things into the server software, like ad-hoc reporting, that used to be handled by client applications).

In the code base that I work with on a regular basis, we have Win32 C++ code that predates the introduction of the C++ STL (circa 1994), C# 2.0 code and ASP.Net 2.0 code. In a perfect world, we’d like to bring everything up to the present and port it all to the latest .NET Framework 3.5, Visual Studio 2008, C# 3.0, whatever Microsoft’s catch-all term is for it. And we’d like to switch to the latest SQL Server version. And we’d like to write unit tests for everything. And we’d like to fix some other things. And so on.

Porting from .NET 2.0 to 3.5 should be relatively painless, but moving 14-year-old C++ code is not something to be taken on lightly. So, several things have become clear to us as we inch towards The Big Port:

1. You should have a good reason to port. This point can be restated as: “If it ain’t broke, don’t fix it.” This doesn’t just mean that the code works as written, which it probably does, but that it could be “broken” in other ways. Maybe it’s not written to be called from multi-threaded code, maybe it won’t run on the latest OS version, maybe it can’t interface with a library that it needs to, etc. Situations like this are reasons to consider porting to a better language/framework for what you want to do.  Another potential reason to port is because it’s easier or cheaper to find developers for the new platform than for the old one.
2. A port is a rewrite. Unless we’re talking about just switching to the latest version of a framework, changing languages means starting from scratch, especially when it comes to module architecture. You might be able to directly copy some method bodies over with little change, but you should accept the fact that different tools make developers think about old problems in new ways. This is probably a Good Thing in the long run, since you’ll hopefully get better software than you had before the port, all other things being equal. This is assuming you had a good reason to port in the first place (point #1).
3. Ports fix old bugs and introduce new ones. Whole classes of bugs can be virtually eliminated by using the right language. For example, memory management issues are significantly reduced in a managed, garbage-collected language like Java or C#. This isn’t to say you don’t need to worry about memory management in these languages, since you obviously do in order to write efficient code, but you’re not going to crash with a segfault. Switching from a dynamically-typed language to a statically-typed language will catch certain problems at compile-time, with the possibility of introducing different problems at run-time.
   More importantly, you’re getting rid of an established code base and starting with a fresh, virgin code base. There’s going to be issues to work out before it reaches the maturity of the old code base.
4. Ports take time and cost money. Duh. Well, they probably take more time and cost more money than you expect, which is always the case with software.  More importantly, you’d generally want those most experienced with the old code base to be responsible for porting it to the new platform, so it would be expected that the old product would suffer from a lack of maintenance.

Unless you’re in a cowboy coding environment, this should all be self-evident.  However, it underscores the importance of thinking clearly about projects before taking them on.

January 30th, 2008 | | Subscribe to comments | Leave a comment | Trackback URL