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.
Establishing a time reporting system within an organization can be a very challenging task, but it presents important advantages once the system is in place. Let’s face some hard facts about time reporting:
-
Time reporting is necessary: if you don’t know how much time the team is spending on each task, you’ll hardly know if the original effort estimates for the tasks were correct. Also, time reporting allows you to keep historical data that will be helpful in estimating future projects and optimizing your processes.
-
Time reporting is overhead: of course time reporting is not part of the main tasks that your team members are supposed to execute. Because of this, your time reporting system must be fast, friendly and easy to use. If a team member spends more than five minutes reporting his/her hours, then something’s wrong with the system. Also, if a project manager or team leader has to spend hours chasing team members that haven’t reported their hours on time, then there is definitely a problem.
-
Time reporting is cultural: nobody really likes time reporting when it is first introduced. If there is no plan to communicate the advantages of time reporting to team members, they will probably be reluctant to report their hours in a periodic and timely manner. Basically, you have to sell everybody the idea that time reporting is important and key to the project’s success. Organizations that have succeeded at creating a time reporting culture now possess extensive historical data and knowledge about their own processes.
Last week, a developer from a company that is evaluating a trial version of the Visual Basic Upgrade Companion sent us an email, asking if they should use the Microsoft Visual Basic 6.0 Upgrade Assessment Tool and the Code Advisor. Perhaps someone else has a similar doubt, so I thought it may be a good idea to share our response here.
First of all, let's remember that we are talking about three separate --and different-- tools:
- Visual Basic Upgrade Companion (VBUC): this is ArtinSoft’s Visual Basic 6.0 to VB.NET/C# migration tool. Basically, you use this tool to convert your VB6 code to .NET.
- Microsoft Visual Basic 6.0 Upgrade Assessment Tool: this tool was written for Microsoft by ArtinSoft, and can be downloaded free of charge from http://www.microsoft.com/downloads/details.aspx?FamilyID=10c491a2-fc67-4509-bc10-60c5c039a272&DisplayLang=en. The purpose of this tool is to generate a detailed report of the characteristics of your VB6 code, giving you an idea of the size and complexity of the code from a migration standpoint. The tool itself does not make any modification of conversion of the source code.
- Code Advisor: this tool is also provided by Microsoft, free of charge, and can be downloaded from http://www.microsoft.com/downloads/details.aspx?familyid=a656371a-b5c0-4d40-b015-0caa02634fae&displaylang=en. The Code Advisor analyzes your VB6 source code and looks for particular migration issues within the code. Each issue is marked with a code comment that suggests how to modify the VB6 code to avoid the problem.
The purposes of the Microsoft Visual Basic 6.0 Upgrade Assessment Tool and the Code Advisor are different, so it is recommended that you use both of them. However, it is important to note that the Code Advisor was designed for users that plan to migrate with the Visual Basic Upgrade Wizard (the conversion tool that comes with Visual Studio .NET), and since VBUC has a greater migration coverage, some of the issues that will be flagged by the Code Advisor will be fixed automatically by VBUC. For a detailed discussion on those issues, please refer to my article “Visual Basic Upgrade Companion vs. Code Advisor”: http://www.artinsoft.com/VB-Upgrade-Companion-vs-CodeAdvisor.aspx
During a migration project, the issues that your team will face may tend to become repetitive. Because of this, it is important that you have mechanisms that allow team members to share the knowledge that they have earned in the process of migrating the application. This way, you are not likely to have a team member struggling to fix a migration issue that someone else in the team already knows how to solve.
An ideal way of sharing team knowledge during the migration process is the creation of a Project Knowledge Base, where team members can post the solutions that they have applied to previous migration issues. With a good knowledge base, developers will be able to make searches and retrieve information that will help them fix the issues that they are facing, possibly increasing team productivity and reducing costs.
To be effective, your project knowledge base needs to have the following characteristics:
- Easy access: team members should easily retrieve information as well as add new items to the knowledge base.
- Search capability: of course, you don’t want team members navigating the knowledge base for hours to find a solution to a problem.
- Periodic backup: place the knowledge base on a server that is being backed up regularly. In a later project, the information stored may be useful again.
It is common to implement these knowledge bases using a Wiki engine. More information on Wiki can be obtained at http://www.wiki.org/wiki.cgi?WhatIsWiki.
Also, some examples of popular wiki sites are Wikipedia (http://www.wikipedia.org/) and Memory Alpha (http://memory-alpha.org/en/wiki/Portal:Main), this last one is a personal favorite :)
The other day I heard a joke about project managers told by John Valera, one of the Project Management professors at Costa Rica's Universidad Nacional, so I wanted to share it in this space. I’m not really good at telling jokes, but here it goes…
There was a big project which had three key team members: a software architect, a QA leader and a project manager. These three guys used to go together for a walk after lunch, to relax and talk about the project. One day, they came across an old lamp and when they picked it up, a genie appeared and said:
- “You have awaken me. I’m supposed to grant you three wishes, but since you are three, I will grant a wish to each one of you”.
First, the QA leader said:
- “I wish to flee to some place where I can have all the money that I want, and spend it in whatever I want!” Suddenly, he disappeared and became a rich man in Las Vegas.
Then came the software architect:
- “I wish to flee to some place where I don’t have to worry about anything, and I can have all the fun in the world!” Suddenly, he disappeared and found himself walking in the beautiful beaches of Rio de Janeiro.
At the end, it was the project manager’s turn. With no need for extra thinking, he just said:
- “I wish to have those two guys back at work by 2:00 PM!!!!” :)
End users are sometimes ignored when planning a migration project. Traditional software development methodologies often lack an appropriate level of involvement from the end user, and this can limit end-user satisfaction with the final product. Before you begin a migration, it is important that you understand the needs of the users of the original application: after all, they are the ones who will use the migrated application in their everyday activities. Be sure to gather the following information on the perception that end users have on the original application:
-
Features that the users dislike: sometimes the users consider that certain features of the original application are not suited to their needs, or should be improved. If this is the case, you will be migrating something that the users don’t like, so you can expect the same disapproval when you finish the migration. Because of this, it’s a good idea to make the necessary improvements after you reach Functional Equivalence on the target platform. On certain cases, rewriting those particular features or modules can be a good option too.
-
Features that the users depend on: in several applications, you will find that there are features the users can’t live without, and even the slightest change of functionality could cause a problem. For example, in a data-entry form that is designed for fast-typing users entering lots of information, something as simple as changing the TabOrder of the form controls could be disastrous.
Of course this list is not exhaustive, so be sure to involve the end users form the beginning of the project and gather enough information from them. Whenever possible, make their needs part of the requirements for the migration or the post-migration phases.
Product Managers are among the most important --and influencing stakeholders in a migration project. Actually, they are the “owners” of the application that is being migrated and because of this, they may be reluctant to approve changes to the application.
In many cases, it will not be possible to reach the state of Functional Equivalence in a target platform with 100% the same user interface features as the original application. For example, Tab Controls in Visual Basic 6.0 don’t respond to click events when they are disabled, so the user cannot see the contents of the tab. In Visual Basic .NET, tab controls still respond to click events when they are disabled, so they display their contents in a disabled state. This visual difference is intrinsic to the way the .NET control behaves, and therefore it should be regarded as an expected change after the migration.
Just like the one I mentioned, there may be several changes in the application as part of the migration process. It is very important to make Product Managers aware of these expected changes, and have their approval before the changes are made. Product Managers will have great degree of influence on your migration project, so do your best to keep them on your side!
The developers of a legacy application tend to have an important sense of ownership of the application: probably they’ve spent many months in its design, coding, stabilization and maintenance tasks. Also, they’ve got a lot to say about the future enhancements that should be made to the application, especially taking advantage of the features of the target platform after a migration is done.
In addition to this sense of “fatherhood” over the source code, developers have the best knowledge of the nuts and bolts of the application. Naturally, no one knows the code more than the ones who actually wrote it. Because of this, developers are among the key stakeholders that you must take into account when managing a migration project.
You may find the following tips useful when working with developers as a stakeholder group in migration projects:
-
Most developers will feel very enthusiastic about the migration project. If they are part of the team that executes the migration, they will help keep the team motivated. If they are not in the team, it’s always a good idea to keep them informed of the technical details of the project.
-
Some developers, especially if they are part of the team in charge of the migration, will feel tempted to do some enhancements to the application during the migration project. This may introduce some sort of “feature creep” to the project, possibly increasing the testing and stabilization costs. I guess you don’t want this, so make sure everybody stays focused on the goal of achieving Functional Equivalence first!
-
Developers who are not skillful yet on the target platform will feel rightfully concerned about the migration project. Of course, they need training! Make sure they receive proper training on the target language and technologies before the migration project finishes and they have to continue their maintenance tasks in the new platform.
There are several key questions you need to ask yourself regarding each particular stakeholder that identify in your project. Answering these questions will help you understand these people’s needs and concerns, and will allow you to classify them so you can communicate the right message to each individual stakeholder or group of stakeholders. Some of these questions are:
Note that this list is not exhaustive, as more questions may be necessary depending on your particular situation. Once you have answered these questions, you will be able to classify project stakeholders into several groups, based on their influence, authority, concerns and informative needs. This will allow you to focus on the most important stakeholders (without abandoning the other ones, of course!), and to project the most appropriate messages about the migration project to each stakeholder or group of stakeholders. Keeping important stakeholders on your side will help pave your way to a successful migration project!
In the next posts, we will take a look at some of the typical stakeholders in a migration project.
Stakeholders are people who will somehow be affected –positively or negatively-- by your migration project. In a typical migration, you will be able to identify stakeholders that perceive the project with great enthusiasm: they know that having their applications moved to newer technologies will improve their work, making them more productive as developers and even as end users. On the other hand, some stakeholders will be afraid of the results of the migration project. For example, some developers may fear that their skills will become obsolete in the new software platform, while some managers may worry about the possible disruption that the transition to the new system may generate, and some end users may want to minimize the learning curves that the new version of the application may mean to them.
In an organizational context, you can’t execute a project without taking stakeholders into account. Sooner or later, they will show up in your project to influence it according to their needs or preferences, which in turn may result in helpful support or frustrating disapproval.
The first step that you have to take regarding stakeholders is identifying them. Look around you and identify those people that in some way will be affected by the migration project. Make a list of identified stakeholders, then try to identify their interests and the way in which the project may cause an impact to each one of them.
A key word in stakeholder management is communication. You will be able to deal with the different stakeholders in your project if you learn how to communicate with each one of them, and this is what we will cover in the next few posts.
Migration projects can be quite complex. When you take an application built on a legacy platform and port it to a new language, numerous changes have to me made to achieve the state of Functional Equivalence in the target platform. Because of this, it is recommendable to make Functional Equivalence the most immediate goal of the project, leaving any desired improvements to the application as post-migration tasks. This way, no additional bugs will be introduced due to new code or application changes.
Project leaders should always keep this in mind when directing a migration, since new requirements and improvements will add extra complexity and risk to the migration project. Exceptions to this rule are those improvements that are automatically performed by the migration tool, such as the conversion to Structured Exception Handling and the conversion to ADO.NET that are executed by the Visual Basic Upgrade Companion.
Application improvements can be done gradually once Functional Equivalence has been reached. In the case of migrations to .NET, applications can be improved in a step-by-step process to take advantage of the features provided by the target platform. Some of the improvements that are recommended as post-migration tasks are:
-
Code Refactoring based on the Object Orientation features of .NET.
-
Implementation of Web Services.
-
Changes to the User Interface.
-
Performance Testing and Tuning.