3 Reasons Why VB6 is Dead

VB6 has had a long run as a premier rapid development tool. It stands as the last member of the classic Visual Basic line that started way back in 1991 with VB1. VB6 itself was released a little over 9 years ago in April of 1998 and has seen considerable use over these years in a myriad of business, commercial and individual applications. Programs written in it are used every day by millions of people. So why do I say it is like the parrot in this famous Monty Python skit?

Here are my reasons:

1. It will not be updated or supported by Microsoft

Microsoft has made it clear that they will not release any new versions of Classic VB either as part of Visual Studio .NET or standalone. Furthermore, they won’t be releasing new patches or fixes for it. This means that if a new security problem is found tomorrow the most likely advice Microsoft will give will be, “Upgrade to .NET to fix the problem.” No amount of complaints, unflattering press, online petitions will change this. .NET is where Microsoft wants Windows developers to be so that’s what they’re going to promote, come hell or high water.

2. It is outdated technology

As I mentioned above, VB6 was released in 1998. A lot has changed since then, particularly with the continued rise and importance of the Internet. Sure, there are a lot of things VB6 could do Web-wise but, unfortunately, there are newer tools, such as .NET, Ruby on Rails, and Java, that are new and/or have been updated to take advantage of the most recent trends while VB6 has languished.

Also, Windows has continued to change. With Vista, there are many things you have to do in order to use VB6 with it and to deploy VB6 apps to it that you didn’t have to do previously. Remember that when VB6 was released Windows 98 was brand new but now you would have to look around a lot to find systems still using it, particularly in businesses of any size. Changes to Windows promise only more troubles for VB6 applications going forward.

3. It is a career dead end

When you consider your career as a professional programmer you have to understand that not expanding your skill set beyond VB6 is a serious career limiting move. Fewer and fewer companies are hiring contractors and permanent employees for purely VB6 programming positions. And, to make matters worse, the positions that are available are often maintenance positions that offer little or no opportunity to develop new code. Instead developing new applications, you’re likely to be working on old, poorly written, applications that exhibit what I call the Winchester House effect from being patched and patched again by a legion of programmers over the years.

To make matters worse, these places are often unpleasant places to work, so much so that I’ve come to refer to them as “VB6 Ghettos”. You’ll often find them staffed with people who have little or no ambition to improve their skills, who jealously guard their ‘secret’ knowledge from you, and who are often lacking in application design skills. Nasty office politics reign supreme as people try to protect their position.

So those are my reasons why I think VB6 is dead as an application development tool for Windows programmers.

In a way, I hate to see it go. I wrote a lot of code in it, enough so that I was considered an expert in it. I enjoyed creating programs with it and I knew it inside and out. I signed the MVP online petition asking Microsoft to bring VB6 back. I had done some work with VB.NET 2002/2003 and that world was frightening and confusing to me. But, after spending 3 years in a VB6 ghetto and then leaving it, I quickly came to the conclusion that if I was going to have a career in software development I had to leave the old VB6 world behind and either learn .NET or LAMP/Java ways.

A lot of VB6 programmers are still trying to deny that VB6 is gone. They try to nail it to its perch, bump it and say it moved or contend that it’s pining for the fjords but when it comes down to it VB6 is a dead parrot. You may think that .NET is a slug and hardly a replacement but unless you’re planning a new career as a lumberjack, that’s what you’ll have to learn if you want a decent job.

What are your thoughts? Do you think VB6 is dead? Do you think it still has some life in it? Leave a comment and let me know what you think.

Add comment July 18th, 2007

Extending My.Computer.Audio To Play MP3’s

The My.Computer namespace in VB.NET 2005 provides several ’speed dials’ to various system functions. For example, it can be used to play WAV audio files. Unfortunately, it can’t play other media types like MP3, WMA or MIDI so that limits its usefulness. However, you can extend this, or any other My namespace class, by using partial classes. That’s what I’ll be demonstrating in this article.

For this demo, I used the “PlayingSounds” project from the 101 Visual Basic Samples for WinForms examples from MSDN. These little demo programs are great quick examples on how to do a number of things in VB although they often need a few loose ends tied up to make them work their best.

To get started, we open up the Application Events module. This module exposes the My namespace where we can add functionality to our applications. I covered using it in this earlier article: Tip Sheet: Application Events. Now we need to add a Partial Class to the My namespace to overload the Audio property, like so:

Partial Class MyComputer

Overloads ReadOnly Property Audio() As Audio
    Get
        Return New Audio
    End Get
End Property

End Class

This returns our own Audio object rather than the built in one. Now we are ready to create our own Audio class to play the additional sound files.

First, we need to load a reference to Windows Media Player. So, we go to My Project and the References tab and select “Add Reference”. WMP is a COM object so we select that tab and pick Windows Media Player (wmp.dll) from the list.

Next, we start our own Audio class by inheriting the base Audio class:

Public Class Audio
    Inherits Microsoft.VisualBasic.Devices.Audio

The next part of our code contains a shared reference to the Windows Media Player as well as a indicator of the type of sound we’re playing, if any. Since we only want to play one sound file at a time we use a shared variable here. Also an enum for the sound types is added. We want to keep track of which type of sound is loaded into our audio object since system sounds will use the original Audio class. Here’s the code:

Private Enum SoundTypes
    NoSoundLoaded
    WmpSound
    WavAudioSound
End Enum

Private Shared SoundType As SoundTypes = SoundTypes.NoSoundLoaded
Private Shared WMP As New WMPLib.WindowsMediaPlayer

Now we want to create our overloads for the Play function. The first one has no parameters:

Public Overloads Sub Play()
    If SoundType = SoundTypes.WmpSound AndAlso _
                WMP.playState = WMPLib.WMPPlayState.wmppsPaused Then
                    WMP.controls.play()
    End If
End Sub

In this routine we want to continue playing the currently loaded sound if we’re playing a sound using Windows Media Player and the player is paused. Otherwise, we want to ignore this command. Note that the AndAlso ’short circuits’ the If..Then so if the type is not WMP the state of the player isn’t checked.

Our next two Play overloads allows us to pass in a file location to play. Note that this can be either a local file location or even a URL on a web site. The first only accepts a file location and sends the actual processing to the second play routine which also accepts the Microsoft.VisualBasic.AudioPlayMode.

Public Overloads Sub Play(ByVal fileLocation As String)
    Play(fileLocation, AudioPlayMode.Background)
End Sub

Public Overloads Sub Play(ByVal fileLocation As String, _
                                   ByVal playmode As Microsoft.VisualBasic.AudioPlayMode)
    If SoundType <> SoundTypes.NoSoundLoaded Then
        Me.Stop()
    End If
    Select Case New FileInfo(fileLocation).Extension.ToLower
        Case ".wma", ".mp3", ".mid", ".wav"
            WMP.URL = fileLocation
            Select Case playmode
                Case AudioPlayMode.BackgroundLoop
                    WMP.settings.setMode("loop", True)
                    WMP.controls.play()
                Case Else
                    WMP.settings.setMode("loop", False)
                    WMP.controls.play()
            End Select
            SoundType = SoundTypes.WmpSound
        Case Else
            Throw New Exception("Invalid File Type")
    End Select
End Sub

We want to stop any sound that is currently playing first and then load the new sound into Windows Media Player and play it. If the file extension isn’t a recognized type, we throw an exception. Another approach would be to try to play anything passed to the player and capture any exceptions raised by the player object or to simply ignore any invalid file names without raising an exception. If the second parameter passed in to the routine is AudioPlayMode.BackgroundLoop then we want to play the file over and over until it is stopped. Otherwise, we only want to play it once.

Our remaining Play overloads call the base class. In addition to this call, we add code to stop the currently playing file and an indicator of the file type being played. For the system sounds overloads we add an overload to the standard Play method for this purpose as well as overloading the base PlaySystemSound method.

Public Overloads Sub Play(ByVal systemSound As System.Media.SystemSound)
    If SoundType <> SoundTypes.NoSoundLoaded Then
        Me.Stop()
    End If
    MyBase.PlaySystemSound(systemSound)
    SoundType = SoundTypes.WavAudioSound
End Sub

Public Overloads Sub PlaySystemSound(ByVal systemSound As System.Media.SystemSound)
    If SoundType <> SoundTypes.NoSoundLoaded Then
        Me.Stop()
    End If
    MyBase.PlaySystemSound(systemSound)
    SoundType = SoundTypes.WavAudioSound
End Sub

Public Overloads Sub Play(ByVal mediaData() As Byte, _
                                             ByVal playMode As Microsoft.VisualBasic.AudioPlayMode)
    If SoundType <> SoundTypes.NoSoundLoaded Then
        Me.Stop()
    End If
    MyBase.Play(mediaData, playMode)
    SoundType = SoundTypes.WavAudioSound
End Sub

Public Overloads Sub Play(ByVal mediaStream As System.IO.Stream, _
                                             ByVal playMode As Microsoft.VisualBasic.AudioPlayMode)
    If SoundType <> SoundTypes.NoSoundLoaded Then
        Me.Stop()
    End If
    MyBase.Play(mediaStream, playMode)
    SoundType = SoundTypes.WavAudioSound
End Sub

Now that we have all the play routines taken care of, we’re ready to stop the playing.

Public Overloads Sub [Stop]()
    Select Case SoundType
        Case SoundTypes.WmpSound
            WMP.controls.stop()
        Case SoundTypes.WavAudioSound
            MyBase.Stop()
        Case Else
            'do nothing - if desired, add code to throw an exception here
    End Select
    SoundType = SoundTypes.NoSoundLoaded
End Sub

In this routine we use our sound type enum to determine which method we should use to stop the sound. Note that the Stop routine name is in brackets so that the compiler won’t get it confused with the base VB command of the same name.

Lastly, we add a Pause method. This isn’t in the base class but we’re extending this base to add new functionality.

Public Sub Pause()
    Select Case SoundType
        Case SoundTypes.WmpSound
            WMP.controls.pause()
        Case Else
            'do nothing - if desired, add code to throw an exception here
    End Select
End Sub

Files being played in the base Audio class can only be stopped and started but by using WMP we can pause them as well. This adds another useful function to our new inherited class.

The rest of the application is simply a few improvements to the example program. I added in a pause button checkbox and made a few other enhancements to the program, such as adding in XML comments and improving the file lookup. The code should be fairly self-explanitory but feel free to ask any questions about it here in the comments section. Also, if you notice any bugs or have suggestions for enhancements, please leave a comment.

You can download the code for this project here: PlayingSoundsPlus Code Example

3 comments July 17th, 2007

5 Development Team Productivity Killers

Here are 5 things that will seriously harm the productivity of a software development team. They are:

1. Not Sharing Information
2. Not Using Peer Code Reviews
3. Not Enforcing Coding Standards
4. Not Using a Version Control System
5. Not Using the Appropriate Technology

I’ve seen these things slow down and even kill several projects both in VB and other languages. In this article I’ll go over these common problems and give you some solutions to help you deal with them.

1. Not Sharing Information

It is common for programmers to horde information, particularly from newly hired developers or contractors or from members of other development teams. Why do they do this? There can be several reasons. One typical reason is pure office politics, protecting ones own position in the department and company. Certain human resources policies, like Forced Ranking, can
encourage this behavior. Others may include a fear of criticism by others or feeling protective about others possibly changing their code. Some may even feel like they’re protecting the company from losing valuable intellectual property by withholding key information from other developers.

This kind of ‘tribal chieftain’ knowledge quickly becomes a liability to the company because new developers have to constantly bother the ‘chief’ with questions, thus lowering the productivity of both. Even worse, it can kill team morale if the ‘chief’ is difficult to deal with. And, should the ‘chief’ leave the company, often development projects are thrown into chaos for months.

The solution to this problem is to encourage a free flow of information and find ways to reward it. For example, you may create a mentoring program where a long time developer is given the task of spending some time with new developers to get them up to speed. Or a ‘lunch and learn’ program could be implemented that would allow a small group of developers to discuss things over an always popular free lunch. These approaches and others like them usually build team cohesiveness and spread knowledge more evenly throughout the department.

2. Not Using Peer Code Reviews

Some people view code reviews as a waste of time, a productivity killer, but I think the opposite is true. As mentioned in the first item, too often one programmer doesn’t know what the other is doing. Peer reviews are another way to encourage knowledge sharing. Also, from a productivity stand point, having an extra set of eyes check the code will greatly reduce costly rounds of maintenance since often a programmer is too close to their code to spot problem areas or simply miss things that they meant to repair and forgot about later.

3. Not Enforcing Coding Standards

Nobody likes be in the role of ‘code police’ but some commonality is needed when more than one person is working on a project. If everyone goes and does their own thing it makes code harder to review and maintain. The most important thing here is to come up with an agreed upon standard and stick to it. You may want to use a VB.NET standard coding guideline like this one or you may want to continue to use old style VB6 standards. But, whichever you pick, stick with it and enforce it.

As a side note to this, any good coding standard should include comments. .NET makes this easy with XML Comments since it provides an easy to use and documentation tool friendly common template for them. Of course, you can use your own standard here but XML comments make this task much easier in .NET.

4. Not Using a Version Control System

This is common in organizations that started out small with one or two developers and expanded. Nobody had the time to implement a version control system or there wasn’t money in the budget for it. Soon, as the number of developers increase, the problems start. Nobody is sure which code is actually in production. Programmers find their code doesn’t work or is left out of a release. Rolling back to a previous version is impossible since nobody knows where the original code is located. Hacks to get things to work become commonplace. Soon the whole development process is bogged down in trying to maintain code that can’t be pieced back together.

You can save this kind of trouble by implementing a version control system from the start. It will more than pay for itself in the long run.

Also, everything should go into version control, not just application code. Web pages, documentation, and especially database table structure and stored procedure scripts should be included as well.

5. Not Using the Appropriate Technology

Too often programmers get stuck in the “I have a hammer so everything looks like a nail” approach to designing and developing applications. For example, a team may spend time developing a web based application when a desktop one would be a better choice or vice-versa. Another common trap is to always use a 3rd party code library for everything when it is only appropriate for a small subset of applications. Productivity often suffers when programmers try to force a square peg into one of these round holes. I’ve seen small projects expand into huge, time consuming, death marches because of the insistence on using an inappropriate tool for the job.

Avoid this trap by evaluating the practicality of a programming tool or method for a task early in the design phase. Don’t wait until coding has begun to do this. Also, don’t get stuck in the mode of declaring that all projects will use such-and-such a tool and so forth. Don’t shut out your options without proper evaluation on a per project basis.

Add comment July 16th, 2007

Conquering Meeting Madness

Meetings are the bane of their existence for many a programmer but they’re often a necessary evil, particularly if you’re a lead developer. What steps should you take in ensure that your meetings are worthwhile and don’t waste everyone’s time? When should you call a meeting and when shouldn’t you call one? Should you have regularly scheduled weekly team meetings? What time of day is best for scheduling meetings? In this article I’ll examine these questions.

When should you call a meeting?

In general, a meeting is called for when one or two people need to provide information to a larger number of people quickly or when real time interactivity between participants is required.

Here are some situations where a meeting is called for:

• When there is a need to convey sensitive information at the same time to a number of people. For example, management or other organizational changes, layoffs, work policy changes or other confidential or sensitive matters.
• A demo or training session on a new tool or product.
• When the subject at hand would benefit from a meaningful, interactive, discussion by those invited to attend, for example, a joint application development meeting.
• A brainstorming session to solve a problem that could not be resolved by other forms of office communication.
• When key meeting participants are only going to be in the office for a short amount of time, for example, a meeting with a consulting team or vendor.

Here are some situations where a meeting is NOT called for:

• To communicate work status to other members of a project team
• To deliver project status to project sponsors
• To make it easier for a manager to keep tabs what everyone is doing
• To ask and answer questions like, “What have you accomplished this week?”
• To hand out work assignments

What about having regularly scheduled weekly or bi-weekly team meetings?

My take on this is that these meetings are a waste of time. In most cases, very little information is exchanged, programmers hate the disruption of their work routine and thought processes, they are ineffective for team building and managers or meeting sponsors often feel that they have to fill in the time block with something, even if it is trivial. Also, lazy managers will use them to gather status reports and to pass along information to individuals rather than the team as a whole.

My advice is to avoid calling for any regularly scheduled meetings. Instead, gather status information and make trivial team and company announcements either individually in person or through email or an online forum/blog/wiki format.

What time of day is best for scheduling meetings?

If you must schedule a meeting avoid scheduling one during the middle of the morning or middle of the afternoon. When you do this, you almost guarantee that you will disrupt the work flow of all of the attendees for that half of the day.

Some people recommend meeting first thing in the morning or at the end of the day. This works sometimes but you have to be mindful of individual work schedules and the commute situation in your area. For example, you don’t want to schedule an 8:00 AM meeting when some of the participants regularly arrive at 9:00 since they won’t be there and having the meeting later will disrupt the morning for the early birds. The opposite applies to late afternoon meetings. Also, early meetings can be unexpectedly disrupted when people arrive late due to commuting difficulties, a common problem in most larger cities.

Scheduling just before or just after lunch is generally better since it avoids disrupting the work day as much. However, people will tend to be distracted as lunch time nears and stomachs begin to growl. After lunch works good although some people tend to be a little lethargic at this time.

My favorite time for meeting is lunch. If the matters being discussed aren’t too confidential or don’t require props in the office, take everyone out to lunch at a favorite restaurant. Perhaps you can even get a place with a small meeting room. If the meeting needs to be in the office, order in pizza, Chinese, sandwiches or the like. A free lunch is appreciated by all and people will view it as a nice perk and a long lunch rather than just another boring meeting.

What steps should you take in ensure that your meetings are worthwhile?

Here are some steps you can take that can help you have an effective meeting:

• Before you call a meeting know what you want to accomplish with it before you call it. If you don’t know or are not sure, postpone it or call it off until you’re ready.
• Have an agenda and stick to it. Often meeting sponsors will allow the meeting to stray off topic. Avoid this trap by having clear discussion goals that are known by all attendees in advance and by keeping the discussion focused on the topic at hand during the meeting.
• Achieve the goal of the meeting, even if conditionally. Don’t use the lack of a concrete decision in one meeting as an excuse to schedule yet another meeting. Instead, reach a conditional consensus and an agreed upon follow up plan that doesn’t require more meetings.

One final idea

If you’re the lead or manager, don’t use the meeting to hand out tasks. This tends to make meetings more dreaded by your team and tasks assigned this way tend to be incomplete and vague. Instead, follow up the meeting discussion with emailed or one-on-one in person assignments. You’ll find this to be a more effective use of your personal time as well as the team members.

Add comment July 14th, 2007

The 7 Steps of Software Development - Revisited

Gaëtan Voyer-Perrault read my story entitled The 7 Steps of Software Development and posted his take on some aspects of it on his blog. In his opinion, Joe, the lead programmer in the story, deserved to be fired. In this post, I’m going to examine his opinion and do a little more revisiting of the article.

In his post, Gaëtan writes:

When you are the team lead, your job is the protection of your staff and the protection of the project that’s assigned to you.

I agree with this. I often refer to this as being the ’spear catcher’. As a lead, you are accountable to them just as you are accountable to your management. In the story, Joe’s lack of assertiveness and confidence in the lead role made him a push over for a very choleric boss as well as some co-workers. This led to the team being subjected to a very unpleasant work environment and to Joe’s eventual dismissal from his job.

However, the team was able to pull themselves together and produce a product, even if the design was bad. While I didn’t cover it in depth in the story, Joe did lead the team adequately when it came to developing the program. They built it according to the flawed plan they were given within a reasonable time frame. We can assume that when it came to the actual programming work Joe performed that part of his job satisfactorily.

Joe had not had these types of problem on this project during his previous projects over his 6 years with the company. We might assume that the previous development manager, who Joe got along with well, had acted in a project manager type role that insulated him from these kinds of problems. Joe wasn’t prepared to take on these additional aspects of his job and he failed at it.

Gaëtan continues on concerning Joe’s problems getting a meeting with the project sponsor:

If you don’t get a reply in 2 days, you e-mail Brian’s superior and you forward him all previous e-mails.

This leads into a point that I covered in the story, the leadership vacuum at the company. Brian, who was a second tier manager, reported directly to the CEO. This left the IT development organization with nowhere to go if there was a problem since Phil, the CEO, rarely had time to deal with small problems that bubbled up. Instead he would delegate them back down the chain of command and he trusted his managers to make the right choices. Because of this, Brian’s poor management techniques didn’t become an issue until a CIO was hired, well after Joe had been fired.

Could Joe have made a difference by taking more initiative as Gaëtan suggests? Yes, I think so. He might have still been out of a job but he would have fought a good fight and not wimped out as he did almost to the end in the story.

Gaëtan suggests that Joe could take legal action

Joe should have phone numbers on hand for all government-related agencies and for his lawyer and he needs to walk into the HR office and tell them that the bullying ends as of his visit.

Unfortunately, in my experience I’ve found that legal action or the threat of it rarely works against this kind of non-physical/non-sexual/non-racial bullying. Work place bullies like Brian usually know just how far they can push it to avoid trouble since most are well practiced at their ‘art’. You usually have to wait until they cross the line, making a racial epithet, a suggestive comment or lecherous grab, or push or shove, before you can take successful action.

Finally, should Joe have been fired? Gaëtan thinks he should have been. While I think it was the inevitable end result in this case, Joe was a valuable asset to the company. By firing him the company lost someone with key knowledge that could not be easily replaced. Perhaps his social skills were very lacking, but was this a good reason to fire someone? Unfortunately, often it is the reason many a skilled programmer loses their job.

So, what could the company have done to have avoided this fiasco, other than not hiring a major jerk like Brian?

1. Hire Product/Project Manager(s) to work within IT and with project sponsors to improve communication within the company.
2. Make sure that all positions in the management hierarchy are filled within a reasonable time with qualified people while insuring that communication flows well while vacancies are present.
3. Offer personal development training to employees who are promoted into a managerial role, even a minor one like team lead.
4. Have an executive committee that closely reviews new project proposals to insure that they’re feasible.

What should Joe have done to avoid his fate? Gaëtan had several suggestions, but what they distilled down to was that Joe should have been more assertive. I agree with that and I do recommend that socially challenged programmers do things that will help them in this area. This might be taking karate lessons, joining Toastmasters, getting individualized counseling, or something else that helps you improve your skills in this area.

3 comments July 13th, 2007