Hi Matt,
Please get your newsreader fixed so I don't have to preprocess every post
from you before I can read it!
Comments prefixed [JW] inline.
Back and unburied from mail
Ease of migration is a huge, huge goal for us -- always has been, and will
The whole mantra -- the primary mission -- for the recent version of VB,
in planning meetings, design meetings, and right down to the posters
covering our hallway walls, was all about helping VB6 customers move
I have to say the evidence for that hasn't been terribly clear. After all,
you allowed VB6 to go off mainstream support before you brought out VS2005,
which you say has migration as its primary mission.
[Matt] VB6 supportability vs. improving migration are orthogonal issues. A
migration path already existed in 2002 and 2003, during the overlap. We can
(and will) continue to improve migration regardless of the state of VB6
support -- there's a lot of VB6 code out there still.
{JW] In view of the practical difficulties of migration, and the statements
on the subject by various Microsoft people, I think you can only claim that
a migration path existed in the most nominal way - most reports from people
who tried it suggested that the effort involved was of the order of 50% or
more of the original effort required to write the software in VB6 - a far
cry from the 90% automation claimed for the wizard on the launch of VB.NET.
The mere fact that you accept there is still a lot of VB6 code out there is
testament to that. Moreover, it would seem perverse to stop VB6 support at a
time when you know that there is still a lot of VB6 code which you intend to
assist the migration of in the next version of VS. To do this would seem to
undermine the confidence of the very customers who you say you are
especially looking out for in this version of VS.
I'm not saying you aren't interested in getting VB6 customers to migrate -
it just seems to me that as a company you appear to have gone about it in
rather an odd way.
- Making migration of existing VB6 code easier and more robust (not by
adding gosub's or anything like that, but by translating older code to
Tell me, what is the newer construct that replaces Gosub and to which Gosub
is automatically translated in the migration wizard?
[Matt] I think you're mixing the two phrases in that statement -- I'm not
making any implications about specific translations.
[JW] If a relatively easy migration is to be achieved, then older constructs
that are replaced by newer ones need some kind of automated or
semi-automated translation mechanism. You were the one who mentioned Gosub
and translating older code to newer constructs in the same sentence. It
seemed clear that you meant that Gosub was an example of an older construct
for which there is now a translation. Are you now saying that there is no
such newer construct for Gosub? If so, do you have an alternative example of
an older construct for which a translation has been introduced in VS2005?
- Bringing back functionality that VB6 users loved and relied on (edit and
continue) and adding specialized help for new functionality (error
correction, snippets) to help ease the learning curve.
Ah, here you are making what I suspect is a common error - confusing the
issue of migrating skills with the issue of migrating code. For those with
large VB6 projects to port, E&C in VS2005 is of little practical use unless
and until the VB6 project can actually be migrated into VS2005.That is why
my question was very specific about the migration of code.
I well remember from the time of the original launch of VS.NET that VB6
developers who raised the issue of code migration being derided (at times by
people from Microsoft) as being unable to take on new skills, when they were
in fact very clearly talking about the time and expense necessary to rewrite
existing projects. Please be aware that my questions are very specifically
about the migration of existing medium-to-large VB6 projects.
[Matt] No confusion at all. There are two issues with migration -- getting
people there, and keeping them happy while they're there. Just focusing on
migrating the code would be a mistake. I understand that that's the primary
focus of your question, but I view them as joined at the hip.
[JW] If you understood the focus of my question, let's not spend any more
time digressing from it. Suffice to say that if you are expending
significant efforts in keeping people happy after they have moved when
moving is still a distant prospect for most, then I would respectfully
suggest this indicates a need to invert the relative positions of the cart
and the horse.
- Making a commitment to providing powerful tools for data access, to
provide a leap similar to that seen with VB3, but that was designed for the
That might be very useful to some people, but it is nothing at all to do
with migrating code.
[Matt] It's all about assuring VB users that migration means added power,
and as such is mostly relevant to my previous point.
[JW] I'm sorry, but that *isn't* relevant. If it were, you could claim every
new feature in the product as being part of your focus on migration. If you
really do make such a claim, then all I can say is that your focus on
migration could result in you adding no features at all that actually assist
people attempting to migrate. And, based on what you have told me so far,
you haven't yet demonstrated that idea to be false - you haven't yet
mentioned a single new feature included in VS2005 that was included for the
specific purpose of assisting the migration of VB6 projects to VS2005.
Please realise that all the added power in the world is not going to be of
any use to a VB6 application owner who finds the migration process
prohibitively expensive in time and effort.
So, to summarize in similar language as you gave below: VB.NET was and is
intended to be the successor of VB6. The migration path was sometimes
difficult in VB.NET 2002. It improved in VB.NET 2003. It got rather more
easier in VS 2005, and the "experience" evolved to match.
You haven't yet given me any examples of things in VS2005 that make
migrating code easier. For instance, what has been done to reduce the number
of "ToDo" statements generated by the migration wizard?
[Matt] I have no such list at hand (other than the memory of collecting the
lists of improvements and sending them to Tactics for approval, along with
the other non-migration fixes that VB would send along). If you like, I
could always follow up with the migration team to see if they had such a
list
[JW] I see. No list, no examples. Nothing immediately comes to mind that you
had as bullet points to present at the VS2005 launch event. A promise to
look something up. By all means, yes please, I would like to see such a
list. In fact, if you are serious about VB6 migration, that list ought
already to have been extremely prominently displayed on the MSDN website,
for instance on VBRun
http://msdn.microsoft.com/vbrun/, which is where you
encourage VB6 developers to congregate. But I just checked there (again),
and there is nothing. If migration is so much the focus for this version of
VS, I would have expected a veritable flood of new material on how much
easier migration is now than before. Where is it?
Also, when planning the migration features for VS2005, did you get in touch
with those customers who publicly criticised the migration capabilities of
earlier versions of VS.NET to see what their needs were for the purpose of
porting substantial VB6 projects to VB.NET?
[Matt] Yes. (I personally was involved with this to some minor extent; in my
case, I visited several enterprises in SE Asia (while we were on the World
Tour in 2004) who had concerns with the difficulty on migration, but that's
a tiny example of a much larger effort. We hosted migration labs targeting
problematic migration scenarios, sent folks to customer sites to assist,
and -- the best part of living in the blogosphere age -- got more active in
talking to customers from newsgroups and forums.)
[JW] I know of several people who are well-known to Microsoft (MVPs and
former MVPs for instance), who Microsoft has been assiduous in avoiding. One
who I know particularly well has large vertical-market applications written
in VB6, and who is about to start a serious migration to Delphi. This fact
is well-known to senior people in Microsoft and yet no contact has been made
to discuss migration issues with him. (As he mentioned to me recently, his
phone ain't ringing, so they can't be calling!)
Were your site visits specifically targetted at companies who had expressed
such concerns, or were the concerns mentioned during the course of visits to
companies you had arranged to see for other reasons?
Based on your statements, it would appear that, whatever your intentions,
the previous versions of VB.NET could not reasonably be regarded as a new
version of VB with migration capabilities meeting the standard I described.
Would you say that you have hit that mark with VS2005?
[Matt] I can only summarize my previous statements: the language has evolved
(irrespective of my personal view that VB.NET can also be viewed as a new
presentation of an established theme), and work continues to make sure that
code written in previous versions can be more easily migrated and that the
environment that greets a person upon migration is a comfortable place to
be. I'm not reading a "standard" out of what you've written. I do know that
there's always going to be more we can do with migration. Where's the line
where you'd say "good enough" -- i.e., the "mark?" I dunno -- that's a
qualitative judgment that the community would have to make.
[JW] It is a *quantitative* cost-benefit judgement that individual
application owners have to make. It is a simple question. How much time and
effort is necessary to move the project from the version of VB where it
currently resides to the latest version, and what do I get out of it?
If migration requires less than 2% of the effort it took to write the app in
the first place, it's a no-brainer - you go as soon as you are satisfied
that the new version is stable enough for your purposes. The benefit of
working on the current version with the currently supported platform with
the latest additional features is almost always worth it.
If it is around 5%, you have to think a bit harder about timing it so that
it doesn't clash with a deadline for a major feature, but most people would
regard that as do-able, and getting to the current platform a worthwhile
benefit, provided there are a few features there that you think will be
significantly useful.
10% means you start having to seriously justify the productivity or feature
improvements that would come about as a result of devoting 10% of the
lifetime R&D budget to a migration. That is a significant expenditure. It
requires you to think in terms of some feature you want to add that would be
impossible or prohibitively expensive to add using the old version, and a
significant revenue stream that would not happen without it.
If it is in the region of 20% or more you probably figure that you daren't
take the risk, especially if you worry that next time the platform changes
(as it assuredly will in due course) you will have it all to do over again
because the language has again had major changes.
If you have a legacy app written in VB6 that has had three upgrades since
its original release, each of which cost about half the budget of version 1
of the app, then a 20% rewrite for porting is the cost of an entire new
version of the app - for no additional feature content at all! Try
justifying an entire release-worth of R&D budget on a process that gets you
no new features, and watch the smoke coming out of your CFO's ears!
That is why I set the figure at about 95% automated - any worse than that
and serious questions need to be asked about justifying the time, cost,
effort and risk in a commercial environment. You aren't giving me confidence
that you are anywhere near that figure yet. That leads me back to my
original question - was migration to that standard of automation ever an
objective for you, and do you think you have achieved it yet?
