I just came back from executing a Ready assessment for a company in Minnesota, where I analyzed 740,000 lines of code in a VB6 application, of which 660,000 belonged to a single Visual Basic project (.vbp). This is actually the largest single .vbp I have seen so far, beating the previous record of about 500,000 lines of code held by an European company. We have migrated plenty of applications that contain 1+ million lines of code, but they are usually distributed across many .vbp’s.
Though unusual, single vbp’s of this size are perfectly manageable from a migration standpoint, and here are some things that can be done to deal with them:
- Ensure that the migration computer has at the very minimum, 3GB of RAM.
- Look for customization opportunities before you start migrating the code. Customizing the VBUC for this specific VBP can reduce manual effort drastically.
- When making manual changes, start with a small team until you get the project to compile, especially if migrating to VB.NET as the compiler has a maximum of build errors that it can show at any given time.
- Once the application compiles, increase the team size and go for Visual Equivalence by distributing the different forms and user controls across your developers.
Crystal Reports was one of the most popular reporting engines in VB6, and still holds a strong market presence with its .NET version. However, the object model in the .NET version of Crystal has changed so dramatically from the VB6 days that automating this conversion is not be cost-effective in most cases. These are the options when dealing with Crystal Reports in an application to be migrated to .NET:
- Use COM Interop: we have successfully migrated many applications with Crystal Reports through COM Interop. However, this only works when the report objects are populated using Crystal’s own querying engine (for example, sending a SQL string to Crystal so it can retrieve the data directly from the database), instead of providing an already-populated RecordSet as a data source for the report. This is because once the application is ported to .NET, its RecordSets will become ADO.NET DataSets (or Helper Classes inheriting from DataSet), which will not be compatible with the legacy version of Crystal. This can be fixed this by disabling the conversion of ADO to ADO.NET, but this is not desirable in most enterprise applications, and may compromise future maintainability and enhancements.
- Replace with Crystal .NET or another .NET-compatible reporting engine: this is also a popular option among our clients, as it removes the legacy Crystal component. On the other hand, this replacement is manual and will require adjustments to the report layout, if converting to the .NET version of Crystal, or even a rewrite of the reports if migrating to other engines.
Some time ago, I helped a British company to
prepare and plan for their in-house migration project. One of the first things that we checked were
the project effort estimates, so we could build a work breakdown structure
based on the estimated effort for each activity; both the company’s developers
and ArtinSoft’s had made separate estimates for the project so we could compare
and discuss them.
To my surprise, the company’s estimates were
significantly lower than ours, so we started digging into the details to find
where the biggest discrepancies were, and realized that their estimate
consisted of developer effort only, with no testing or administrative work. They were so focused on manual changes,
Upgrade Warnings and compile errors that they omitted the QA process necessary
to validate that the application is stable and working as the original
one.
As with other development projects, migrations
do require a full testing of the converted application before it is released to
production. You may find less bugs than
you would if you were coding from scratch, but the complete QA cycle is vital
in order to ensure stability and Functional Equivalence. Also, don’t forget to include effort for
administrative tasks as well as other activities that you may have in your
projects, depending on your project management methodology.
Last March I attended the Microsoft Inner Circle conference in Bellevue, WA, in which they presented the 2008 version of Visual Studio Team System. This was my first view of VSTS, and I was impressed by some of the features they included to help developers in tasks such as gathering statistics on their source code, writing and executing unit tests, and looking for potential performance bottlenecks.
We were also introduced to Visual Studio Testing Edition, which contains a set of tools to help QA teams automate tasks such as tracking and managing stabilization processes, controlling code churn and performing load tests.
From a tester’s or developer’s perspective, I have no doubt that VSTS is going to be a great tool; however, I think it still needs to extend its support for Project Management tasks, as well as database design and requirements elicitation, documentation and tracking. We were told that many of these features will be included in the next version of VSTS, code named “Rosario”.
More information on VSTS can be found at http://msdn.microsoft.com/en-us/teamsystem/default.aspx
Just a quick post to wish all readers a happy and prosperous year 2008! :)
One of the
questions that most people ask when preparing for a Visual Basic 6.0 migration
to .NET has to do with the difficulty level of migrating an application to C#
compared to VB.NET.
Although the Visual Basic Upgrade Companion product can migrate VB6 code to both VB.NET
and C#, and both languages are first-class citizens in the .NET world, having
access to all the resources provided by the .NET Framework, there are some key
differences that will make a migration to C# demand more manual effort and
changes. The following are two of these differences:
- C# is
strictly typed as opposed to VB6 and there’s no way around it. Invoking a property or method
from an Object variable that is meant to be instantiated to a different
type at runtime would require a type-cast; otherwise the compiler will
throw an error. Therefore, many late-bound operations and unsafe
operations (such as assigning the value of a Long variable to an Integer
variable) that unfortunately were common in VB6, will generate compilation
errors. This will not happen in VB.NET unless you turn Option Strict on,
which is turned off by default.
- In C#,
only Structured Error Handling (“Try Catch”) is allowed. This means that any error-handling
code that could not be converted to “Try Catch” by VBUC will have to be
fixed manually, implying an important amount of manual work in some
projects (especially if statements such as “On Error Resume” and “On Error
Resume Next” are used in the VB6 code). On the other hand, VB.NET still
supports Unstructured Error Handling (“On Error GoTo”) for compatibility
with migrated applications, which will reduce the amount of manual work if
you are in a hurry. For VB.NET migrations, VBUC can disable the
conversion of “On Error GoTo” to “Try Catch” to speed up the migration
process and reduce manual changes.
Naturally,
strongly-typed and well-structured code is preferable. However, this increases
the amount of manual work that is needed to achieve Functional Equivalence.
More information on migrating Visual Basic 6.0 to C# can be found in the ArtinSoft
website:
http://www.artinsoft.com/vbc_csharpgen.aspx
During the planning stages of a migration project, many customers ask about the ideal profile that the members of the migration team should have. The job of migrating an application is very technical, so having skilled developers is a must. After several migration projects, we have identified a basic set of characteristics that are very desirable in the developers that will port an application to a new platform:
-
Advanced knowledge of the target platform: while migrating the application, developers will face the challenge of implementing a set of features and behaviors of the source platform that are not directly available in the target technology. This cannot be achieved without a high degree of knowledge of the destination platform.
-
Migration knowledge and experience: naturally, having developers with previous experience in migration projects is quite helpful. As these developers are not very common, here is where ArtinSoft consultants are most helpful in a joint migration project.
-
Knowledge of the application to be migrated: during the migration process, many lines of code, methods and classes of the original application will have to be manually changed or adjusted to work in the new platform. Since there will be a constant modification process until the application reaches Functional Equivalence, knowledge of the internal structure and coding of this application is very desirable. In a joint migration project, here is where customer’s developers are most helpful.
One of the most important metrics that we use to measure the size of a Visual Basic 6.0 code base to be migrated is called Effective Lines of Code. This measurement represents all those lines that will require a certain amount of migration effort and in the case of Visual Basic 6.0 to .NET migrations, it includes the following:
- Visual lines of code: this includes all the code that is automatically generated by the VB6 forms designer. This code belongs to .frm and .ctl files and is not visible to the programmer (if you open a .frm or .ctl file in a text editor such as Notepad, you will see this visual code at the beginning of the file). The reason why we include this as part of the code base to be migrated is that VB6 user interface also represents a manual migration effort, together with VB6 source code.
Naturally, the Effective Lines of Code metric does not include blank or comment lines since they do not imply any migration effort.
Working days, or business days, are usually said to be 8 hours long. On an average day, you may get to work at 8:30 am and leave by 5:30 pm, having 1 hour for lunch (although this differs from one culture to another, just ask someone from Mexico and you’ll see what I mean!).
Anyway, people usually spend 8 hours at work everyday. However, this doesn’t mean that people are 100% productive in the tasks they’ve been assigned to during those 8 hours. During a normal working day, normal people also check email, make phone calls, talk to their coworkers and do other things that are not necessarily related to the tasks they are working on. As a result, working days are pretty much like soccer games: while a soccer game is said to last 90 minutes, the effective playing time is usually much less than that. Likewise, the effective working time in an 8-hours business day is lower than 8 hours.
The amount of effective hours may vary from an organization to another and from an individual to another. Organizations that keep good project metrics may have a better idea of the average number of effective working hours per day. The important thing to keep in mind here is that even when a team member may be assigned full-time to a task, it cannot be assumed that he or she will devote 8 hours per day to that task. Therefore, it makes sense to think that a task that has an estimated effort of 16 person-hours will take a little more than 2 days to complete with one resource.
In order to get the most from a time reporting system, several requirements should be met. Historical data that is accumulated in the system will be more accurate and meaningful depending on the way team members report their hours.
Periodicity is very important. Time reports are usually more accurate when team members update their hours daily. If reporting is done weekly, team members will hardly remember how much time they spent on each task at the beginning of the week.
Insist that team members report their hours accurately. Sometimes people don’t work exactly 8 hours a day, so when time reports are “flat” (i.e. 8 hours every day), you may be looking at a symptom of inaccurate reporting.
It is also important to break down the tasks in meaningful sub-tasks, so team members won’t be confused when reporting their hours. If possible, include a description of the tasks; this description will serve as a future reference for post-mortem analysis and historical data retrieval.
Finally, it is not recommendable to use reported hours as a criteria to reward team members. Doing so may introduce more biases in the reports and may cause a negative team response.