This blog has been moved to

Friday, November 30, 2007

Multi-threading just got a little bit easier

Microsoft has just announced that they have "released an early preview of the Parallel Extensions to the .NET Framework (ParallelFX) technology." I haven't had a chance to check this out yet, but it looks like it will provide a new API for managing threading. What looks especially interesting are the multi-threaded foreach loops.

I don't want to say too much because I really don't know much about it, but check out the announcement on Somasegar's blog, Parallel Extensions to the .NET FX CTP.

Sunday, November 25, 2007

Qualitative vs Quantitative Results in Usability Testing

As regular readers might already know, I am taking a certificate program in User-Centered Design. This quarter I am taking a class on usability testing.

One of the things I've learned in the course is that there seems to be a debate on qualitative vs. quantitative results. For the sake of this post, I'll define them as thus:

Qualitative - descriptive, subjective. Not easy to provide objective measurement.

Quantitative - numerical, objective. In sufficient quantity can provide statistically significant facts.

As you can probably imagine, most people would like to see quantitative results. They are easy to understand and see just how important a particular issue might be (not to mention those cool graphs). However, due to budget and time constraints, it is extremely uncommon for a usability test to have a sufficient number of participants to qualify for statistical significance. Without statistical significance, are quantitative results useful?

image I have to say emphatically no. Quantitative results are completely useless within a usability test. The goal of usability testing should be to find flaws in the design (from the users perspective) of the software. These flaws should be tracked and prioritized the same as any other defect within the application (hopefully you use issue/bug tracking software).

Usability testing should focus on qualitative feedback. There are many techniques that you can use to elicit feedback from a user (for example, thinking out loud). Post study questionnaires can also be useful, but the questions should be open ended. You can ask a participant to rate the software, but only to lead them to the next question which should ask why they rated it the way they did (the actual rating is useless without statistical significance).

Furthermore, when reporting the results of usability tests, it is important not to imply any kind of statistical significance. For example, don't say that 20% of the participants failed to complete a task when you only had five participants. For all you know, that participant is the only person on the planet that would fail or perhaps the other four just got lucky. Even mentioning something like 1 out of 5 can be dangerous. Always make sure that people that are reading your report understand the limitations of the data.

Monday, November 19, 2007

Visual Studio 2008 and .NET Framework 3.5 shipped!

This just in, Microsoft has shipped Visual Studio 2008! Read Somasegar's Weblog for the official announcement.

I can't wait to try it out. I'm looking forward to trying out all the new features such as XML literals in VB.Net, improved Intellisense, LINQ, integrated unit testing, and much more.

Hopefully I will get a chance to purchase a copy from the MS store soon. Are there any MS employees reading this that wouldn't mind if I bought this on their quota? I don't work too far from Redmond :).

Friday, November 09, 2007

.Net 3.5 Poster Available

The Commonly Used Types and Namespaces poster for version 3.5 of the .Net framework is now available.


It main sections are Windows Presentation Foundation/Windows Forms (in green), ASP.NET (in yellow), Communications and Workflow (in orange), Data, XML and LINQ (in purple), and Fundamental (in blue).

The poster lists new types as well as what will be available in the 3.5 version of the compact framework and Silverlight 1.1.

There is a lot of new stuff in here. Here is a quick list of what's new in each section:

  • WPF/WinForms
    • Nothing
  • ASP.Net
    • System.Web.ApplicationServices
      • AuthenticationService
      • ProfileService
      • RoleService
    • System.Web.ClientServices
      • ClientFormsIdentity
      • ClientRolePrincipal
      • ConnectivityStatus
    • System.Web.ClientServices.Providers
      • ClientFormsAuthenticatonMembershipProvider
      • ClientRoleProvider
    • System.Web.Configuration
      • WebConfigurationManager
    • System.Web.UI
      • ScriptManager
      • UpdatePanel
      • UpdateProgress
  • WCF/WF
    • System.Net.PeerToPeer
      • Cloud
      • PeerName
      • PeerNameRecord
      • PeerNameResolver
    • System.Net.PeerToPeer.Collaboration
      • ContractManager
      • PeerApplication
      • PeerCollaboration
      • PeerContact
      • PeerNearMe
    • System.ServiceModel.Persistence
      • PersistenceProvider
      • PersistenceProviderFactory
      • SqlPersistenceProviderFactory
    • System.ServiceModel.Syndication
      • Atom10FeedFormatter
      • Rss20FeedFormatter
      • SyndicationFeed
      • SyndicationItem
    • System.ServiceModel.Web
      • WebGetAttribute
      • WebInvokeAttribute
      • WebOperationContext
      • WebServiceHost
  • Data/XML/LINQ
    • System.Data.Linq
      • DataContext
      • EntityRef<T>
      • EntitySet<T>
      • Table<T>
    • System.Data.Linq.Mapping
      • AttributeMappingSource
      • Metamodel
      • XmlMappingSource
    • System.Xml.Linq
      • XAttribute
      • XDocument
      • XElement
      • XName
      • XNamespace
      • XNode
      • XText
  • Fundamentals
    • System
      • TimeZoneInfo
    • System.AddIn.Contract
      • IContract
      • INativeHandleContract
    • System.AddIn.Hosting
      • AddInProcess
      • AddInStore
      • AddInSecurity
      • AddInToken
    • System.AddIn.Pipeline
      • ContractBase
      • ContractHandle
      • CollectionAdapters
      • FrameworkElementAdapters
    • System.Collections.Generic
      • HashSet<T>
    • System.Diagnostics
      • EventSchemaTraceListener
    • System.Diagnostics.Eventing
      • EventDescriptor
      • EventProvider
      • EventProviderTraceListener
    • System.Diagnostics.Eventing.Reader
      • EventLogInformation
      • EventLogReader
      • EventLogRecord
      • EventLogWatcher
      • EventRecord
      • ProviderMetadata
    • System.Diagnostics.PerformanceData
      • CounterData
      • CounterSet
    • System.IO.Pipes
      • AnonymousPipeClientStream
      • AnonymousPipeServerStream
      • NamedPipeClientStream
      • NamedPipeServerStream
      • PipeSecurity
      • PipeStream
    • System.Linq
      • IQueryable<T>
      • Queryable
    • System.Linq.Expressions
      • Expression<T>
      • Expression
    • System.Runtime.Serialization.Json
      • DataContractJsonSerializer
      • JsonReaderWriterFactory
    • System.Security.Cryptography
      • ECDsaCng
    • System.Threading
      • ReaderWriterLockSlim

I found the add-in support particularly interesting. I have been planning on implementing add-ins for the next major version of our product and am hoping to be able to use the add-in support in .Net 3.5. If you are interesting in finding out more about this, check out the article .NET Application Extensibility and the CLR Add-In Team Blog.

Thursday, November 01, 2007

Creating A Build Process

Jeff Atwood had a great post today about automating your build process (The F5 Key Is Not a Build Process) and it inspired me to finally write this post (I promised it a while ago - Making the Build).

As mentioned in my post Making the Build, an automated build process is very important. However, most software teams have a tight schedule and budget and find it difficult to justify spending time creating a proper build process, especially when nobody on the team has previous experience creating an automated build process.

Before I get to the benefits of an automated build, let me first describe the build for our product.

Our build process is fully automated. We have it scheduled to run on a dedicated machine every night. The build includes many different things, including compiling the source code, building the database from the previous version of our product using scripts, generating some source code, updating assembly attributes (such as version, company, etc), running unit tests, and more (too project specific to bother mentioning).

The benefits that we have found for our team are as follows:

  1. Frequent builds -  Before we automated our build process, it was run manually (though we've always had scripts and utilities to help). Unfortunately it was sometimes weeks between builds. If there was a problem with the build it was very difficult at times to track it down.
  2. Standard builds - Back when we ran our build process manually, it was not always run the same way. Often times steps were skipped because they took too long and didn't seem important (sometimes it wasn't, but when it was, it could take a lot of time to figure out what the problem was).
  3. Build status visibility - Every developer gets an email every day about the status of the build. If the build fails due to something they checked in, it is usually easy to find the problem because it is only a single days worth of code and was checked in only yesterday - hopefully they still remember what they worked on yesterday :).
  4. Easily get the latest build - The build process places the completed build (at least the parts of it the developer cares about) into a shared directory that all developers have access to. To run the build, they can simply copy the build onto their machine and run a simple utility to attach the database. This makes it very easy to debug problems with the build.

If you decide to create an automated build process, here are a few suggestions (some of the advice is specific to building .Net projects, but I think much of it should hold true for other technologies as well):

  1. Fully automated - I can't seem to mention this enough :). The process should be able to run in the middle of the night on an unattended machine without any manual setup or teardown process.
  2. Run regularly - The sooner a problem is found, the easier it is to fix. We build nightly, but many people build even more often than that.
  3. Run in a clean environment - In order to prevent false positives with a build (the build succeeds but shouldn't have), the first task in your build should be to create a clean environment (create a new directory or clear out the directory that you are using). This is especially important in finding circular references.
  4. Use proper tools - You don't want  We use FinalBuilder. The tool provides a visual interface for creating your build. I would not recommend using batch files, MSBuild (as your primary build tool anyway), or NAnt. These can be very difficult to maintain. You don't want to get into a situation where every time you want to make a tweak you have to relearn the whole build process. If your team has a dedicated build engineer, then MSBuild or NAnt are great tools.
  5. K.I.S.S. - Keep It Simple, Stupid. The simpler you make the build process, the more likely it will be for people to use it correctly. For example, in our build process, the only thing developers need to do to integrate their project with the build is to check it into the correct location in VSS. We have a utility that will make sure all the projects get compiled in the correct order based on the references in the project file (Compiling Multiple Projects Without a Solution).
  6. Don't underestimate the effort - It took me a couple of weeks full time to create our current build process. Of course once it's setup, and assuming you used the proper tools, it should only take a few minutes to make adjustments when necessary.

Many people also advocate that build should be able to be run by any developer on their machine. This hasn't been very realistic for our project due to the size of the project and the cost of the software we chose to use (FinalBuilder isn't exactly free). However, it is a goal that I approve of.

If your project doesn't currently have an automated build process, I hope this article has encouraged you to create one. Good luck.