WordBasic to VBA conversion: An odd question

Since I am an odd person, guess I can ask an odd question.

ASSuME that you know everything there is to know about converting WB to VBA. Of course, no such person likely exists, but let's make believe.

Such a person would be able to look at each WB statement and almost instantly determine what needs to be done to replace the code with VBA.

My question is "How many statements per minute do you think such a person could manually convert?".

For we mere mortals, that number is likely less, so how many statements per minute could we mere mortals expect to manually convert?

Well... if you know what the original statements are and what they do, and immediately know how to rewrite it in VBA then I would say 1-5 statements per minute.

Quote:

---

Originally Posted by DRJ

Well... if you know what the original statements are and what they do, and immediately know how to rewrite it in VBA then I would say 1-5 statements per minute.

---

So at 5 per minute, it would take 782 minutes to convert 3910 statements.]If a program did the conversion in 13 minutes, that program would be quite valuable, n'est-ce pas?

Using the above numbers the program is about 60 times faster than the manual method, so if the hourly rate for the manual effort is $N, charging anything less than $N per minute to use the program is a bargain.

I would go for the lower end of Jake's range - or even less than that. Doing 150 lines in half an hour (the upper end of the range) might be possible but I don't think anyone would sustain that rate for very long.

(Assuming you make no effort to automate any of it) where there is a straighforward one-to-one correspondence you would still have to type in the replacement code. Where there isn't (for example Wordbasic Sort) you would get slowed down a lot. And I don't know what you would do with statements like DisableAutoMacros where the only way to do it is via the WordBasic method from VBA.

Hi Howard,

Just saw your reply after I posted.

Conversion is a difficult business. Yes, a program could be worth a lot but you would have to factor in the code it couldn't convert which would still have to be done manually.

Quote:

---

Originally Posted by TonyJollans

I would go for the lower end of Jake's range - or even less than that. Doing 150 lines in half an hour (the upper end of the range) might be possible but I don't think anyone would sustain that rate for very long.

(Assuming you make no effort to automate any of it) where there is a straighforward one-to-one correspondence you would still have to type in the replacement code. Where there isn't (for example Wordbasic Sort) you would get slowed down a lot. And I don't know what you would do with statements like DisableAutoMacros where the only way to do it is via the WordBasic method from VBA.

---

A few years ago, I developed a tool that does do automatic conversion.
It is if course far from complete, and I've never used it for a client.

Debugging the tool is rather difficult. If used during an actual full WB to VBA conversion, any glitches would likely be spotted when compiling the code and converting the rest of the statements.

However, somebody recently contacted me about doing a WB to VBA conversion, so maybe it's time to bring the tool out of the closet and use the tool on other folkes templates.

So, I'm trying to figure out what to charge.

A couple of years ago, I gathered some info on 9 templates.

The percentage of WB eliminated ranged from 25.62% to 65.42%, so the effectiveness does indeed depend on how WB is used.

The largest template (quite complicated) had 21946 lines of code, the WB object was used 7000 times. 3910 were eliminated by the program in 752963 milliseconds, that's 55.86%.

The least effective case appears to have been a template that had 1870 total lines. 843 uses of the WB object, and 216 were eliminated, or 25.62%. The time used was 331377 milliseconds.

I was thinking of two ways to charge for using the program:

1. A flat rate per minute, no matter how (in)effective was the conversion.

2. A minimum rate per minute plus a higher rate depending on the % of WB objects removed. I like this, because the program is rewarded when it can be most effective and that gives the most benefit.

There is also the cost of my time to set up the run. Rather low as I run this from a global template that will convert the attached template or a batch of templates in a "work" directory.

And then, I do have to spend a few minutes, compiling and perhaps searching for obvious booboos.

Quote:

---

Originally Posted by TonyJollans

Hi Howard,

Just saw your reply after I posted.

Conversion is a difficult business. Yes, a program could be worth a lot but you would have to factor in the code it couldn't convert which would still have to be done manually.

---

Yes, but a large cost of the conversion is the tedium.
Only a true masochist, and one who knows both WB and VBA fairly well, should do such conversions.

Certains things cannot be done automatically and an even larger part, in particular Dialog boxes, has to be rewritten anyway.

In the process of doing a conversion it is almost a certainty that the WB code will be found to be buggy and the conversion will expose more errors.

I don't know what MSFT plans on doing to facilitate importing the WB object into a .NET-ized Office. I, actually my piggy bank, hopes that folkes have code that will need to be converted due to the .NET-izing of Office.

I forgot to state my opinion to my original question.

In a WB to VB conversion, the actual rate has to be less than 1 statement per minute merely because much of the effort will be in recoding dialog boxes and other critters that do not easily convert syntactically.

An EXPERT in WB and VBA could eyeball search and pick the easy ones, but the process of searching takes time and thought, so even 2 per minute seems a stretch. The typical person doing a WB to VBA conversion is, likely, not really an expert

Programmatically getting rid of the easier statements, would greatly reduce the tedium, and likely make the rest go faster.

Hi Howard,

I don't really know WB, so don't know all the pitfalls in this one, but I have done many (sometimes tedious) conversions over the years (cross-platform and cross-language) and bugs in original code are certainly a problem. Also a problem is the inadvertent reliance on buggy or undocumented environment features.

As for charging, I like the idea of charging by the minute regardless of success - but wouldn't be so keen on it as a buyer. In my experience charging per line of code is more normal, but it is a rule of thumb and you need to see some sample code before quoting a rate.

Quote:

---

Originally Posted by TonyJollans

Hi Howard,

I don't really know WB, so don't know all the pitfalls in this one, but I have done many (sometimes tedious) conversions over the years (cross-platform and cross-language) and bugs in original code are certainly a problem. Also a problem is the inadvertent reliance on buggy or undocumented environment features.

As for charging, I like the idea of charging by the minute regardless of success - but wouldn't be so keen on it as a buyer. In my experience charging per line of code is more normal, but it is a rule of thumb and you need to see some sample code before quoting a rate.

---

Be thankful that you don't know WB.

Charging by the minute, not based on success, is preferred merely because it avoids my having to count the before and after WB object use. The real benefit is the program finding a lot of the tedious conversions and getting them out of the way.

It's easy enough to cite examples of why the program is a lot less expensive than doing the deed manually.

Charging per line of code is a poor criteria, especially in a WB to VBA conversion, as it is not a matter of just translating syntax. There are almost always algorithmic changes required and it is very difficult to convert WB Dialog box to VBA Userform. Not to mention performance hits that may need to be overcome.

The real problem with figuring out how to charge per minute can be demonstrated as follows.

Earlier in this thread, I assumed that 5 statements per minute could be converted manually. I do not believe that is a practical rate and the real rate would be lower.

So it would take about 782 minutes to find and convert 3910 WB objects.
Assume the programmer charges $85 per hour, then the damage is about $1108.

If the program can do the deed in 13 minutes, and the charge is only $10 per minute, the damage is is reduced to $130 plus a few minutes of manual time to check things out. Let's say, the check out time is 1 hour, so the damage becomes $215, which is a heck of a lot less than $1108. Not to mention, the automatic conversion reduces the tedium, which should make the programmer more effective on the rest of the conversion.

Of course, the client will be wary of the $10 per minute, because that is $600 per hour, but it is still cheaper than doing the deed manually.

Quote:

---

Originally Posted by Howard Kaikow

The real problem with figuring out how to charge per minute can be demonstrated as follows.

Earlier in this thread, I assumed that 5 statements per minute could be converted manually. I do not believe that is a practical rate and the real rate would be lower.

So it would take about 782 minutes to find and convert 3910 WB objects.
Assume the programmer charges $85 per hour, then the damage is about $1108.

If the program can do the deed in 13 minutes, and the charge is only $10 per minute, the damage is is reduced to $130 plus a few minutes of manual time to check things out. Let's say, the check out time is 1 hour, so the damage becomes $215, which is a heck of a lot less than $1108. Not to mention, the automatic conversion reduces the tedium, which should make the programmer more effective on the rest of the conversion.

Of course, the client will be wary of the $10 per minute, because that is $600 per hour, but it is still cheaper than doing the deed manually.

---

Hmmm, did I get an omen that $10 per minute is the optimal rate?

How so, you ask!

Well, the above posting mentions $130 and I just noted that it was my 130th posting in VBA Express.

An omen?

My two cents worth:

WB being a relative dinosaur means that the version of Word in question is also probably from the Jurassic period. Depending on what the code is actually doing, you may find that in a more recent version of Word you would perform the task using a completely different method. Therefore directly translating the code is ineffective.

You also need to consider the author of the original code. Assuming that it was not written by a VBAExpress member, you may be replicating poor programming. If the original was written by a novice or Dodgy Brothers Programming Inc., you will end up with a brand new version of terrible code. Even where the original programming is reasonably proficient, I know that in almost every instance where I have had to revisit code I?ve written 2 years (or more!!) after development, I have always seen ways I could have streamlined or improved upon the original.
Mind you, that $10 per minute does sound attractive ...

Quote:

---

Originally Posted by geekgirlau

My two cents worth:

WB being a relative dinosaur means that the version of Word in question is also probably from the Jurassic period. Depending on what the code is actually doing, you may find that in a more recent version of Word you would perform the task using a completely different method. Therefore directly translating the code is ineffective.

You also need to consider the author of the original code. Assuming that it was not written by a VBAExpress member, you may be replicating poor programming. If the original was written by a novice or Dodgy Brothers Programming Inc., you will end up with a brand new version of terrible code. Even where the original programming is reasonably proficient, I know that in almost every instance where I have had to revisit code I?ve written 2 years (or more!!) after development, I have always seen ways I could have streamlined or improved upon the original.
Mind you, that $10 per minute does sound attractive ...

---

Even if the goal is to totally rewrite the code, there are major portions of code that can be rewriten much faster if first automatically syntactically converted.