VB 6 migration productivity index

[eliassal]

Hi, I need some information on developer productivity in analysing and producing specification for a VB 6 legacy application to a completly different platform (not .Net). All jobs need to be done manullay so any automated approach is ruled out.
I found an interesting tool like Project analyzer but need some figures on how many lines of code a standard developer can transform to business rule per month or per day. I read on Atissoft web site that it ranges from 5000 to 30000 lines of code /month for for .Net migration.

Thanks for your help

[Hack]

Moved To General Developer

[techgnome]

What the heck? You want to know how many lines "a standard developer" can analyze and convert to .NET in a day? or a month? That's hardly a fair assessment. lines of code is irrelevant. It's about the complexity of the business logic in the first place. And it's not like it's always a straight one-for-one replacement of VB6 to .NET... in some cases, it requires a little more effort in .NET. In other cases, it takes considerably less. I absolutely abhor lines of code metrics. It's bullstock... pure and simple. It's a meaningless metric. Example, I chewed through probably close to 15000LOC yesterday... today it's only going to be about 2000 ... so am I less productive today than I was yesterday? Hardly... I had a much more complex problem that I needed to work through. So today I'll only get one task done... yesterday I got 6 done... but they were a bunch of little things compared to today's one big thing. Also most of yesterday's tasks consisted of checking that the issues had actually already been completed. So while it felt good to knock 6 things off my plate, it won't feel as good as it will later today when I mark off this one single significant thing off the list.

LOC metrics are a meaningless metric created by management that doesn't understand that 25 tightly written efficient lines of code is actually better than 100 loosely written lines.
Is the developer that writes:

Dim myInt as Integer = 25

less productive than the developer that does this:

Dim myInt as Integer
myInt =25

or what about the developer that does this:

Dim myInt as Integer
for myInt = 1 to 25
  'this is an empty comment
next

All three accomplished the same thing, but in very different ways... I'll take developer #2 over #3, and #1 over #2.

I've worked in shops where LOC was the barometer... it sucked. Stop looking at LOC metrics for conversion. Heck, don't even think "conversion." Treat it like new development. Start with requirements and blank slate. Write the code from scratch as much as you can. Then be happily surprised when you find chunks of code in your old app that you can port over with minimal fuss. If you don't re-write, all you're doing it upgrading your current bugs and design. Start over. Develop all new bugs and design flaws while fixing the old ones.

-tg

[eliassal]

I compeltly agree with you. However, as I indicated it is not a VB 2 Net, it is VB to another platform.
I personally was a VB developer and done several reverse engineering projects or was handed projects written in VB6 completly by other people to maintain. I had the time to understand and reverse engineer quietly.
Why I am asking this is because since 5 years I didn't do any dev in VB, didn't record time spent on what I did and need/looking for a standard or a base for evaluating an average VB developer can do in 1 day or month extracting business rules/logic. Here I am talking aabout an average developer dedicated for this, not doing anything else.
I thought of LOC right away, also of measuring the complexity of the app.....I am looking for high level figures and not very detailed precise ones, just to help me have an idea 10-30% more or less

[eliassal]

I forgot to mention that in 2003 in the first years of .Net framework 1.0 and 1.1, MS has published some statistics on efforts needed to migrate to C# but can not find it on their web site.

[si_the_geek]

Given the vast amount of things that cannot be known in advance, any estimate will be either very vague or very likely to be wrong.

The estimate you found of "5000 to 30000 lines of code /month", while a bad way to measure, is probably roughly applicable... and you are unlikely to get more accurate until at least having a read thru of the existing code, and thinking about how the same things can be done in the target language.

[Shaggy Hiker]

I would agree that LOC is terrible, but a somewhat better measure for many apps would be number of distinct forms. This will fail for formless console apps, math and AI apps (where the UI is minimal, but the complexity is high), or games. Still, for most DB-font-end business apps, the number of forms seems to be a fair indicator of complexity.

[techgnome]

I didn't think of that... that's probably a better metric... the number of non-trivial forms (a trivial form would be one that does one thing and one thing only - like "Enter Birthdate: [__________]" or doesn't contain any business logic). I'd also add the number of business processes into it as well - this might then cover non-ui apps - for instance, an app may be low in forms... but high in processes... Data Entry, Validation, number crunch, report data generation, reporting.... reporting... I'd hazard a guess that a decent developer should be able to tear down at least 1-2 reports per day, if not more. At a high side though, I'd venture 5 reports in a day tops. And then of course data storage and retrieval.

-tg

[Shaggy Hiker]

That sounds about right to me, too. I'd be less inclined to rule out trivial forms, as anything more than a MessageBox tends to take a certain amount of creativity, but you might be able to rate forms by control count, which suggests that the absolute count of number of controls might be an even more suitable metric. Not all controls are equal in complexity, but in my experience, an individual control has a complexity reasonably similar to any other control, whether it is a label, textbox, or datagridview.