Tag Archives: Productivity

Visual Studio Tip: Using the Task List Pane

I was in a meeting the other day and a question came up about the purpose of the Visual Studio Task List. A couple of the developers had never used it before, so I thought it’d be a good topic for the blog.

Task List tab in Visual Studio

The Task List, by default, appears in the bottom left window pane of Visual Studio (the same place where build errors and warnings appear). Alternatively, you can find it under the View menu. Microsoft provides some basic documentation on the Task List feature here. However, the documentation glosses over some developer best practices, so I thought I’d expand on that a little.

NOTE: Before I go further, I want to preface everything by saying that the task list should not replace more robust issue tracking systems, like TFS Work Item Tracking, Microsoft Project or another 3rd party product backlog or issue tracking solution. That being said, the Task List can be beneficial in defining more granular programming tasks that may not be appropriate in a higher-level work tracking system.

Code Comments vs. User Tasks

Two types of tasks can be captured in the Task List pane: User Tasks and Code Comments.

User Tasks provide generic notes that a developer may want to remember during development. They work pretty much like Outlook Tasks do, except without any of the features that make Outlook Tasks useful. After about five minutes, you’ll quickly realize just how limited User Tasks are. I usually stay away from them because

  • Most of what I have used them for, I should be putting in an Issue Tracking / Work Item Tracking system.
  • User Tasks are not stored in version control; therefore, other developers cannot see them and I lose them if I ever move or delete my local working environment.

Let me spend a moment longer on that last bullet, because I think that’s an important point.

User Tasks are stored in the developer’s *.suo file, which is not stored in source control by default (nor should it be). The *.suo file contains user-specific preferences, such as the state of the Solution Explorer, which should not be shared across developers. When another developer opens a solution for the first time, a new *.suo file will be created automatically.

This leads us to Code Comments, which are much more useful. Code comments are literally comments in your code (hence the name) that have been prefaced with a pre-defined keyword. Creating code comments is a very straight-forward activity:

'VB.NET
Try
    'some code here
Catch ex as Exception
    'TODO: Need to implement roll-back feature in transaction.
    Throw
End Try

 

// C#
Try {
    // some code here
}
Catch ex as Exception {
    //TODO: Need to implement roll-back feature in transaction.
    throw ex;
}

By preceding a comment with “TODO”, it automatically appears in the Task List. As you can see below, it is possible to see all code comments within your project/solution at once:

Image of task list pane

Task List pane with all-important programming tasks

Code Comments improve upon User Tasks in a variety of ways. For example, code comments allow you to “bookmark” your code in case you need to come back to it later for refactoring or a re-design. Also, code comments are in source code. Source code is stored in version control and shared among the development team. See where I’m going with this?

I hope this helped shed some light on another little feature of the Visual Studio IDE.

Check In Code Frequently for Roll-back’s Sake

One of the best practices around source-control is the idea of checking in code frequently. “Frequently” is, of course, a relative term. Some take this to mean checking in code within a matter of hours; others, days. Some suggest check-ins should occur every time a new feature is added. Then the question becomes: What constitutes a feature? Is a method of a class a “feature”? Is a class a “feature”? Is a feature based on a user story? A Use Case? A bulleted item in a requirements document?

For me, I’m prescribe to the practice of checking in per feature. And, by feature, I mean a Use Case (or a single flow of a Use Case), or a backlog requirement. Of course, some features take more time to implement than others. But this is ok. Sometimes, I’ll check in within a couple hours. Other times, I might check in after a couple days. Rarely, however, do I leave files checked out for more than 2-3 days (if that gives you an idea how “large” I spec these features).

key-undo

One of the many benefits of checking in frequently is that you allow the ability to rollback in-progress code changes that are not panning out. For some of you, this may be a completely foreign idea.  “Delete my code?! Are you loco??  This code was spawned from the magnificence that is my brain.  It is precious.”

If that was your reaction,… well, if that was really your reaction, then you should probably stop reading.  Wait, don’t stop reading.  I need the subscribers…  For those of you that had a bit more subtle reaction, consider this anecdote:

This morning, I was coding up a new feature for an active development project. All previous code had been checked in before starting this new feature, so I was starting from a stable build. Starting out, I was trying to figure out the best way to implement this new feature. In some cases, some up-front design and modeling would have been useful – but, in this case, where I was working with a few unfamiliar .NET classes, it made more sense to just try out a few different approaches programmatically and get a feel for which worked best.

In the span of about 90 minutes, I had implemented – and subsequently rolled back – five code changes before finding an approach that finally worked.

Some of the reasons for rolling back the first several changes included:

  • The implementation was not going to work
  • The implementation would have created more maintenance overhead than I wanted
  • The scope of the implementation became much better than what I wanted to bite off

Also while making these development changes, I noticed Visual Studio modifying a number of auto-generated files that I don’t normally touch (including project, .settings and .resx files). It would have been very difficult, if not impossible, to go through these files manually and find all the changes that were made.  But because I was rolling back all of the files via TFS, there was significantly less risk of introducing unstable code (or accidentally leaving leftover code) in a later build.  It was also considerably faster than manually traversing the code for delinquent code.

If you’re not accustomed to rolling back code in your development cycle, it’s feels kind of like this:

  • The first time you intentionally rollback (read: DELETE) your code changes, it’s kind of scary!
  • The second time, it’s a little scary, a little exciting, maybe even a little deviant-like.
  • Subsequent times, it’s empowering. And you wonder why you weren’t doing it sooner.

Control key So if you are (or know someone who is) in the camp where code check-ins are almost an afterthought, consider this example and think about the value that frequent check-ins can add to the development cycle.

The Secret: Wants vs. Needs

Let’s consider the following statement:

Don’t always deliver what the customer wants;
Always deliver what the customer needs.

There’s a subtle distinction between the two parts of the above sentence, but it’s an important one.

Most of us have heard the argument "Do you really need that?" at some point in our lives, usually when it has to do with something we really want, and are willing to argue passionately about its inclusion in the realm of all things necessary. Usually, this "voice of reason" manifests itself as a parent, spouse or some incorporeal, 3-inch tall, white-robed, haloed dude – or chica – hanging out on your shoulder.

But I digress. The point is that it’s a good question to ask ourselves. Do we really need something, or is it just something we desire to have?

Wants vs. Needs in Software Development

All too often, we – the technical folks – will get a long list of requirements from our business stakeholders, some of which are necessary for them to do business, and some of which are fluff features, or “nice-to-have’s”. Unfortunately, it’s also common for these different category of features to be lumped together into the same set of requirements, and it’s difficult for us to tell which is which. It’s our own fault; we’ve conditioned our business partners to think this way.

So how do we tackle the list? Generally, I’ve seen it done one of a couple ways:

  1. We treat all requirements as gospel and just start running through the list until we burn out, project time and/or money runs out, or (rarely) we deliver everything.
  2. We start cherry-picking through the list, based on what we think the business needs.

Both scenarios have major implications. In the first, we risk burning out our teams, the business partners, or both. Burned-out folks tend to leave, or produce lower-quality results. In the second scenario, we are putting the decision of what is important to the business in the hands of the technical folks (as opposed to the hands of those who are actually doing the business work). I’ve got another post planned for this second scenario, so I’ll just leave it at that for now.

So What’s the Alternative?

Half of the Agile Manifesto talks about promoting Customer Collaboration and drawing focus to Individuals and Interactions. So, the first step is to get the business partner involved in the planning of what gets worked on first. After all, they were the source of the requirements, so they should have a good idea of what’s most important to them.

Using iterations (the backbone of iterative and agile methodologies) can also help to promote adaptive and risk-based planning by forcing the team (which includes the business partners) to decide on a subset of requirements to implement during each iteration. Responsible teams will choose features that are the highest priority. (Note the word responsible in that last sentence. Agile practices alone do not a successful team make). Iterations also help the team to "course correct" between iterations of a project if they start going in the wrong direction, or if changing business needs dictate a change in what features are most important.

And while I’ve said this before, I must stress it again. Get the customer / business partner involved. Let them tell the team what they need, and what they want. And, like that voice of reason, the team should sometimes question their needs to make sure they really are needs, and not just a want hidden behind charismatic arguments.

When to Check-In Source Code Changes

For the last couple of months, I’ve been leading an adoption effort at work to migrate developers away from our current version control system over to Microsoft’s Team Foundation Server.  During this time, I’ve been approached with a number of questions regarding best practices around source control usage, causing me to brush up on my own level of knowledge on the subject.

Recently, I was asked the following question:  When should I check in source code that I’m working on? At first, this seemed like a trivial question. But, since I didn’t have a good immediate response at the time, I figured it can’t be all that trivial.

So, upon further reflection – and consultation with several fellow developers – I’ve compiled the following list to be good situations in which committing changes to source control is a good idea.

You should check in files…

  • When the project is first created
  • When a new feature has been written (such as implementing a class, a method or a “slice” of functionality – from the GUI down through data access layer)
  • Before refactoring or re-designing a component (so that there is something to compare with, or roll back to)
  • When a bug has been fixed.

In what other situations would it make sense to check in files to source control?

MSDN Article: Using XML Comments

The May 2009 MSDN Magazine has a good article reviewing XML comments and their usefulness for code development and documentation.  The article is primarily written for VB developers, but the concepts do apply to C# developers as well.

I’ve been using XML comments since Visual Studio 2005 came out.  For your VB developers still developing legacy .NET 1.1 / VS 2003 apps, you can install the VBCommenter add-in, which will give you some of the basic functionality (C# developers have this out-of-the-box).

If you’re not familiar with XML comments – or if you’ve heard of them, but haven’t tried them out yet – give the article a look.

A Coder’s Challenge

I was recently “challenged” by a fellow agile member who claimed that Java developers have a higher maturity level then their fellow .NET developers.  His claim was that .NET developers rely too much on the mouse when programming, which makes them slower because their hands have to leave the keyboard more frequently.  Java developers, on the other hand, are more familiar with their tool (e.g. IDE) and all the keyboard shortcuts that are programmed into it.

So, I considered his claims and his challenge.  I scoured the interwebs, searching for the knowledge I sought that would help me master the .NET coder’s tool of choice (the great Visual Studio), until I found what I was looking for.

And so, for my fellow .NET “adolescents”, I share with you this, straight from our god herself:

You threw down the gauntlet, B.C. and I accept your challenge.