To use or not use Microsoft.VisualBasic.dll (all .NET Languages could benefit?)

I’ve been working on a check list for a code review process we are starting. As a result I’m looking into all kinds of best practice opinions in books and online.

One interesting opinion has been to avoid importing Microsoft.VisualBasic. The reason given was to force developers into using pure .NET code and not older VB6 legacy syntax and keywords.

CInt

I tested the assertion that .NET’s System.Convert.Int32 was faster than the legacy VB6 CInt.

The older VB6 method of converting a string to an integer was almost 20 times slower than that of the .NET Framework.

Here are the CInt results.

Well, as it turns out this is not the end of the story. As I continued testing and comparing the classic VB6 way of doing things against the .NET Framework I found a couple surprises.

1. I found that you cannot have a hard and fast rule stating that the Microsoft.VisualBasic.dll should not be used. In some cases I see that it certainly can and should be used.

2. Not all methods in the Microsoft.VisualBasic.dll exist in the .NET Framework.

3. Work around(s) for Microsoft.VisualBasic.dll methods are sometimes faster and sometimes slower.

4. Equivalent methods of the .NET Framework are sometimes much slower than that of Microsoft.VisualBasic.dll.

These are not the results I was expecting and in fact, they were not the results I wanted. I wanted to prove to myself that I not only didn't need Microsoft.VisualBasic.dll but that it was more efficient to code without it.

I was wrong.

As we saw earlier, the System.Convert.ToInt32 is much faster than CInt and the same is true for all the conversion functions.

IIF

I've always known that IIF was slower than a regular If/Then/Else statement. I had never proven this to myself or taken the time to understand why. Like many things we pick up these tips from other developers and assume the more experienced developer is right. In this case it's true.

IIF performed much slower than using If/Then/Else. What struck me is that I had to turn Option Strict off to use IIF or explicitly convert the results. The reason is IIF returns System.Object. I think this is why it is slower. Maybe someone can confirm or deny this for me.

Here are the IIF performance analysis results.

IsNumeric

The IsNumeric method is one of those Microsoft.VisualBasic.dll methods that I could not find anywhere in the .NET Framework. I was really surprised by this because it is an obvious method that the .NET Framework should support.

What I did in my test was write a quick and dirty method using the TryParse method of the Double class. The Parse method would do the same except when the value passed is not a number an exception is raised. The exception was so expensive that it was better to simply reference the Microsoft.VisualBasic.dll and use IsNumeric; however, the TryParse method returns True/False and does not raise an exception, keeping the method call cheap.

The results here are much of what I expected. The new MyIsNumeric was about twice as fast as the classic IsNumeric method.

The IsNumeric results are below:

Now()

The Now() method of Microsoft.VisualBasic.dll was another suprise. As it turns out, the classic Now() method out performs the new DateTime.Now method by as much as 15 times faster.

I don't understand why but knowing the results does alter my best practices check list.

Here are the Now() method results:

AscW

I was surprised again when I tested VB's AscW. As it turns out there is no equivalent to this method in the .NET Framework as well. This functionality could, however, be imitated by using a conversion method of and Int or Double.

The results are disappointing as the Framework approach was many times slower.

Here are the AscW and Convert.ToInt32 results:

IsDBNull versus row.IsNull

Here is a performance comparison between the classic IsDBNull versus the .NET Framwork DataRow.IsNull method. The .NET Framework version is about 25% faster.

Conclusions

As it turns out, I can't have a hard and fast rule that says never to reference the Microsoft.VisualBasic.dll library in favor of pure .NET Framework code. The best argument for doing so is language portability. Even in that scenario, it seems perfectly reasonable to use the Microsoft.VisualBasic.dll library regardless of what language you are using. C# is as capable of using this library as Visual Basic.

It would seem that Microsoft has a little work to do. These methods should all be framework methods and the Microsoft.VisualBasic.dll library should fade away.

Here is what I will do... when coding I will...

1. Reference the Microsoft.VisualBasic.dll library only if I explicitly intend to use it.

2. I will always use the .NET Framework conversion methods and never CInt, CBool, CLong, etc.

3. I will never use IIF.

4. I'm on the fence with IsNumeric. If I'm already referencing the VB library then I might go ahead and use it but I would not allow IsNumeric to cause me to reference it because writing my own method is more efficient anyway. If I am already referencing the VB library then I would not write my own because I would want to name my method IsNumeric as well and that could cause a conflict or force me to fully qualify it. So that is my compromise.

5. The Now() method also puts me in conflict because the VB version performs as much as 15 times faster. I will opt to use the .NET Framework version because there is a one to one mapping of this functionality and in that scenario I will almost always select the pure Framework version. Having said that, if performance is an issue, I will fall back on the VB version.

6. The VB AscW, ChrW, and other character conversion methods are time tested, high performing, and reliable. I must opt for the classic VB methods over home grow work around(s) in the .NET Framework.

I'm curious what others have to say on this particular topic. I've only spent 2 days looking at these issues so if anyone has some insight, please share it.

Posted Oct 19 2006, 09:58 AM by rdunaway with 2 comment(s)

Filed under: Performance

CAB/SCSF Podcasts Series

http://blogs.msdn.com/eugeniop/

We are using the CAB fairly intensely. I'm not yet convinced it is the right solution for us but you might find it useful for you. There is so much complexity added to our solutions and I have yet to see any real benefit. We have been using it for about 6 months. I’ll have a more definitive conclusion after another few months and when I feel I know something… I’ll post my thoughts.

Here are a series of short podcasts to give you an idea of what CAB can do for you.

Enjoy...

Posted Oct 13 2006, 02:56 PM by rdunaway with no comments

Filed under: CAB, Patterns and Practices, SCSF, Podcast

Some Sad IT Facts

These are fairly known but often dismissed facts about the IT industry. If you see these facts presented you will find IT managers and developers nodding their heads in agreement. That is as far as it goes.

I'm always amazed to see an IT manager hesitate to purchase a piece of software because he is afraid of wasting 300 dollars but there is no hesitation to waste 10's of thousands or even 100's of thousands through his/her indifference to good software management practices.

I found a company that specialized in process. I was very excited to be a part of a team dedicated to making quality software at an affordable cost. One week into this project, I realized that very basic steps were missed. They were not oversights, it was simply thought that gathering quality requirements was not worth the time and effort. I was shocked. Don't these people realize that while not sexy, this is still a critical step in the process?

All quality is related to requirements.

As I predicted, we went over budget around 200 percent. We missed our deadlines on a fix priced project and pissed off the customer. All because gathering quality requirements were not sexy enough. It would seem it was more important to measure employee productivity and create schedules. Of course, it's impossible to measure productivity if you don't have a clear definition of what you are supposed to produce and let's not get into the impossibility of predicting a schedule without requirements.

SIDE NOTE: I'll cover this in another blog, after further thought. NEVER measure your employees for the purpose of criticism. When you do this, you will never get accurate numbers from your employees ever again. It's just a fact of life.

The following are the sad truths of IT:

From the Hugh W. Ryan article of Outlook Journal:

Only 8 percent of application projects costing between $6 million and $10 million succeed.
Among all IT development projects, only 16% delivered to acceptable cost, time and quality.
Cost overruns from 100 to 200 percent common.
Cost overruns for IT projects have been estimated at $59 billion in the United States alone.
IT workers spend more than 34% of their time just fixing software bugs.

Other reports make the following claims:

Only 28% of projects are completed.
In the UK, over $1 billion a year is wasted on poor software quality.
70% CRM project strategies fail.
90% companies cannot show a positive ROI for CRM.

Here is an interesting fact that I, 100%, believe is true but it is still shocking to comprehend the incompetence that must allow this.

"According to the Cranfield School of Management, the more ambitious the return on investment for the project cited in the business case, the more lacking the project plan is likely to be."

Posted Oct 13 2006, 02:41 PM by rdunaway with no comments

Filed under: Requirements, The Craft, IT Industry

Measurable Requirements

Measurable Requirements

Requirements can be measured as good or bad based on requirement attributes. Often our perception of requirements is just that, a perception. Good requirements have specific attributes which can, fairly easily, be measured.

If you find you do not have good requirements and the culture of your organization does not allow you to gather them…. Then that is simply a reality you must work within; however, you should not allow yourself to be disillusioned to what the quality of your requirements is or software will be.

Knowing the actual quality of your requirements will help you to predict the quality of the software you will deliver. Many aspects of quality in software are completely out of your hands. They are directly linked to the quality of your requirements. Knowing this will help you set expectations of quality and schedule performance. Depending on your organization, you may not be able to share your findings fairly as the organization might not want to confront the culture as affecting quality, cost, or schedule but the truth is that more than skill, culture drives these factors…

The following is an excellent article which describes good requirement attributes followed by examples of requirements which have been corrected and an explanation of why they were deficient.

Reducing Risks Through Proper Specification of Software Requirements
http://www.stsc.hill.af.mil/Crosstalk/2002/04/florence.html

.

Posted Sep 27 2006, 01:01 PM by rdunaway with no comments

Filed under: Requirements, The Craft

Perfecting your craft... Why Requirements

Software development as a craft?

As with any profession we should continue to perfect our craft. I'll begin this blog with a discussion about requirements and see where this leads. While I have my opinion on certain matters, I honestly want to know what others think. I remain open to change myself as I know readers of this blog are. On with the journey...

Software requirements are the foundation of any software development effort. Regardless of whether you collect the requirements up front or through-out development, all requirements will be known. If documented they will remain known else they will be known in the form of tribal knowledge.

Why do some resist following process which includes requirement discovery while others embrace it? Is there a cowboy mentality in our community or is it simply more efficient to code a little, gather a few requirements, then code a little more? For those who embrace process, is it possible that a certain comfort is found in a predictable process oriented environment?

So is it worth the effort to develop our craft as software programmers? Should we mature beyond the technical skill set and venture into the unknown?

Requirement Statistics:
What is the unknown? In fact much of this process driven world provides imperial proof of its claims. Here are some facts.

Concerning defects injected into requirements:
Incorrect Facts: 40 percent
Omissions: 31 percent
Inconsistency: 13 percent
Ambiguity: 5 percent
Misplaced: 2 percent

Over 70 percent of defects are due to incorrect and omitted facts.

How much more misunderstanding do we have when no value is placed on gathering requirements?

This is a real problem in our industry and in my mind is part of why software development is not the respected craft it should be. We are often viewed as an expense and in many cases rightly so.

Source of Errors and Cost
According to the "Software Project Management Course Workbook (Pittsburgh, PA.:CMU/SEI/September, 1992). the following facts are true.

The following are where defects are injected into applications:
Requirements definition: 50%
Software design: 35%
Coding: 15%

So if requirements analysis is not held as critical then you can expect your defect rate to be at least doubled.

The following is the cost of fixing a defect at each stage, according to the same study:
Requirements definition: $150 per defect
Software design: $500 per defect
Coding: $1,100 per defect
Testing: $1,200 per defect
Deployment: $7,500 per defect

Conclusion
Nothing else we do seems to matter if requirements aren't collected, scrutinized, and documented. Yes, it can take time but can you afford to not take the time. You will never be the first to market with a quality product without a well defined process and a culture that can deliver it. A process alone cannot deliver on the promise of that process. Software developers should continue to perfect their craft. Software process is a part and a "culture of quality" and should be promoted.

I have been on both sides of this issue but admittedly I am much more comfortable in a predictable environment. So my tendency will always be to promote process and as a human I will seek proof that process is a necessary part of the craft. Having fully disclosed my tendency and bias, I welcome all comments and opinions.