ArtinSoft recently published a number of case studies of Visual Basic migrations for ISVs. The projects were successful both from the technical as well as the economical perspective. If you are an ISV and you are considering an evolution of your application and a port to the .net platform I encourage you to take a look:http://www.artinsoft.com/vertex-omiga-vb-to-net-migration-case-study.aspx
http://www.artinsoft.com/vertex-supervisor-vb-to-net-migration-case-study.aspx
http://www.artinsoft.com/hsi-latnav-vb-to-net-migration-case-study.aspx
In this blog I am trying to be as unbiased as possible in reporting my opinion with regards to VB migrations. This time I am mentioning the case studies as evidence that a lot of the conceptual discussions that I have are actually happening in reality. It is interesting to see how many of the comments to this blog tend to be from skeptics and from people that just love VB6 and do not want to abandon it. My purpose is to show that there is life after VB6 and that an automatic migration is not only possible but, in many cases, a great alternative for your evolution plans.Please let me know what you think of the case studies.
Milan Negovan in his blog aspnetresources recently published an excerpt of Michael Feathers' book Working Effectively with Legacy Code. I liked the excerpt so much and I believe that it is so pertinent to the topic of my blog that I also will reproduce it verbatim.
--
Often people who spend time working on legacy systems wish they could work on green-field systems. It’s fun to build systems from scratch, but frankly, green-field systems have their own set of problems. Over and over again, I’ve seen the following scenario play out:
An existing system becomes murky and hard to change over time. People in the organization get frustrated with how long it takes to make changes in it. They move their best people (and sometimes their trouble-makers!) onto a new team that is charged with the task of “creating the replacement system with a better architecture.”
In the beginning, everything is fine. They know what the problems were with the old architecture, and they spend some time coming up with a new design. In the meantime, the rest of the developers are working on the old system. The system is in service, so they receive requests for bug fixes and occasionally new features.
The business looks soberly at each new feature and decides whether it needs to be in the old system or whether the client can wait for the new system. In many cases, the client can’t wait, so the change goes in both. The green-field team has to do double-duty, trying to replace a system that is constantly changing.
As the months go by it becomes clearer that they are not going to be able to replace the old system, the system you’re maintaining. The pressure increases. They work days, nights, and week-ends. In many cases, the rest of the organization discovers that the work you are doing is critical and that you are tending the investment that everyone will have to reply on in the future.
The grass isn’t really much greener in the green-field development.
--
I concord 100% with Michael Feathers. Rewriting code is something that can be achieved only at a very large rate of consumption of time and money! My thesis is that migration, specially automatic migration, is often the best option. You can easily change the platform and then focus on rewriting/rearchitecting only the pieces that truly deserve it. This has been proven over and over again at ArtinSoft.