My love affair with Visual Studio: Error Correction

I have been working with Visual Studio for years, and I’ve found a few tricks along the way that make my coding easier. In this blog post I’ll show one of my favourite time savers the Error Correction feature.

When you are writing code for a form or a class as part of a team, or even if you are just starting work on a project which will be made up of multiple classes, you always end up having to reference classes, properties, or methods in your code that haven’t been written yet. So you either have to comment out those calls, add them later, or add stubs so your code will compile. In Visual Studio 2010 they added a neat little feature that will add the stubs for you!

Say I am writing code for a click event handler that will create and populate an instance of a Student object who will be registering for a course. I haven’t created the Student class yet so I see a squiggly under the word student and this little rectangle at the end of the squiggly.

Now comes the cool part, I can carefully hover the mouse over the tiny rectangle and a little warning symbol will appear, if I hover just right it will appear with an arrow beside it that I can click on.

Clicking on that little arrow will bring up a menu of options that will fix the error for me! By the way, if like me, you find using the mouse to bring up the list fiddly, you can use the keyboard to bring up the correction menu by putting the cursor on the word student and hitting CTRL + . that’s CONTROL KEY and a PERIOD.

Visual Studio is offering to create a Student class for me, or to define a new type (variable essentially). If I click on Generate ‘Class Student’ I can see a new class appear in Solution Explorer called Student.vb

If I open up the Student class I see it has not only created a class, but because my code called a constructor and passed in two variables, it created a constructor method in the class as well that accepts two variables!

The code isn’t complete by any means, but it’s enough to get rid of the squiggly on Student in my event handler!

Of course now I have squiggly lines under vFirstName and vLastName because I haven’t declared those yet, but if I bring up the Error Correction list for those variables I select Generate field for vFirstName and then Generate field for vLastName and it adds the declarations for me!

Sure, it didn’t’ know what data type to make the variables, it’s not perfect, but when I am trying to test something quickly these little Error Correction tools that will generate code stubs for me can be a real time-saver.

This blog also appears on the Canadian Solution Developer Blog

Another Meeting! Who Really Needs to Attend?

Have you ever been to a meeting where part way through you thought to yourself “I do not need to be here”? It’s happened to all of us. I once asked my husband exactly what he does at work. He thought about it for a minute and answered “I go to meetings.” Meetings are everywhere! Now don’t get me wrong, meetings can be very effective. We want to keep everyone informed, and we do need to consult with different team members when we are making decisions. But how much thought do we put into who to invite to meetings? Most of us err on the side of caution and invite everyone who may have an opinion or wants to be kept informed. After all haven’t we been told over and over again the importance of communication? But sometimes we forget meetings are not the only way to communicate.

I have done a lot of work with the Information Technology Infrastructure Library, better known as ITIL. Don’t worry I am not going to go into a diatribe on the benefits of MOF (Microsoft Operational Framework) and ITIL here and now (that’s a blog for another day). The reason I bring it up is that in ITIL I came across a wonderful model I have applied very successfully. Its called the RACI model (pronounced racey). RACI is an acronym for Responsible, Accountable, Consulted, Informed. This model can be used to help you run more successful meetings. As they say in Kinect Dance Central…let’s break it down.

Responsible –  Who are the people responsible for doing the work? The people responsible should definitely be in the meeting. For example, if you are holding a meeting to discuss a bug fix, you definitely want the programmer who is making the bug fix present to explain the effort required to fix the bug, or to explain the cause of the bug.

Accountable – Who is the person who is ‘on the hook’ for the work? This is often the supervisor of the people responsible. Sometime it helps to think of the A as standing for Authority, as in decision making authority. Who has the authority to make decisions? There should only be *one* person identified as accountable. Otherwise you run into problems. There is a Danish proverb that roughly translated says “When you have one clock in the house you know what time it is, as soon as you have two clocks you are are never sure.” You want the person accountable in the meeting, because if they aren’t there you may find the meeting going in circles because there is no-one in the room with the authority to make a final decision on how to move forward. If the person accountable cannot attend, see if they can appoint someone to attend to act on their behalf with their authority. Otherwise, you may want to reschedule the meeting to a time when the person accountable can attend. For the bug fix meeting example, the operations manager or project manager might be accountable. We want them in the meeting because they will have the final decision on if or when we fix the bug based on the effort required, the impact on the users, and the other team priorities.

Consulted – Who are the people who will want a say in the decision or discussion but are not doing the work itself? Often you can provide these individuals with a summary of the topic to be discussed by email and follow up with them before and after the meeting. They may give you questions that they want answered, but that doesn’t mean they need to attend the meeting itself. Often you can ask the questions on their behalf. If the question is too complicated, then you may invite them to the meeting so they can explain and elaborate as necessary. For example, when you are making a bug fix you may need to consult with the security team to ensure that the fix does not violate security policy. Most of the time, if you let security know what you are going to discuss in the meeting, they will tell you the concerns they need addressed. After the meeting you can let them know the outcomes and give them an opportunity to identify any outstanding issues.

Informed – Who are the people who need to know what is going on? These are the people who need to be kept in the loop, but do not need to attend the meeting. For example, your user community, your client, or the testing team may need to know about the progress on a bug fix but that doesn’t mean they need to attend all the meetings. Often e-mail or a collaboration, project tool like SharePoint or Visual Studio Team System is sufficient to keep them up to date.

So the next time you are invited to a meeting, ask yourself where you fit in the model, if you are not responsible or accountable, do you really need to attend? If you are holding a meeting, complete the RACI model for the topic being discussed. On some projects, I have documented the RACI model for each programming module, or bug. That way when a change or issue was identified we immediately knew who was responsible, who was accountable, who needed to be consulted, and who needed to be kept informed.

So in keeping with the meeting theme, here are

My 5 Tips to successful meetings (there are many more, but I’ll stick to 5 for now)

1. Complete the RACI model for the meeting.
2. Email your agenda, or questions to be discussed one to three days before the meeting. That way everyone has a chance to arrive in the meeting prepared. Don’t send it out to far in advance or they will forget about it before the meeting.
3. Book a suitable meeting room with the required amenities. Make sure you have enough chairs, water, a projector if necessary. It is very frustrating for meeting attendees to spend 20 minutes sitting unproductive while you run around the building trying to find a projector or whiteboard markers.
4. Use a parking lot! Meetings frequently go off track, do not be afraid to have a flipchart or corner of the whiteboard where you can park issues for follow up later. It is important if you use a parking lot that you do leave a few minutes at the end of the meeting to discuss how you will follow up on each item in the parking lot. A parking lot is not meant to be a black hole.
5. Do not deliver surprises in a meeting and expect useful feedback. When someone tells us about a new initiative or change, our first reaction is emotional: I love the idea or I hate the idea. It will take me a little while to absorb what you have told me and give you useful feedback. All too often we walk into a meeting and are informed of a major change, then while we are still reacting to the news we are expected to provide constructive criticism. If you tell me today by email or in person, and give me some time to absorb the idea and mull it over I would be in a much better position to discuss it rationally tomorrow in a meeting.

This post also appears in the Canadian Solution Developer Blog