This Blog has Moved!

I've moved my blog to www.redwerb.com (a domain I've had for awhile, but never got around to using).

I've managed to transfer all my posts to the new blog (though I've lost all my comments in the process). I plan on disabling my Blogger account soon, but I will probably leave the posts up for now.

If you are subscribing to the RSS feed, the new feed is http://feeds.feedburner.com/Redwerb.

Hopefully I will see you on my new site!

The Illustrated Catalog of Common Driving Patterns

Over the last 20 years I have had many opportunities to observe my fellow motorists (especially since I started commuting 35 miles or to work everyday). During this time, I have noticed some very common patterns on the road. These patterns are often annoying and sometimes dangerous (though I'm sure we're all occasionally guilty of some of them).

 

Driving Patterns

Bounce	This is perhaps the most commonly used pattern on the road. A "bounce" occurs when you pass a driver, they speed up and pass you, and then slow down to their original speed within a short period of time.
Freeway Phobia	This driver enters the freeway at a significantly slower rate then traffic. Some of the scariest experiences behind the wheel is trying to enter the freeway behind one of these drivers.
Frogger	The name Frogger comes from the old arcade classic. In this pattern, the driver is attempting to beat traffic by seeking out the fastest lane. Of course heavy traffic can be difficult to predict and in the long run, you usually get the satisfaction of passing them several times.
Pace Car	Drives slowly in the fast lane. Enough said.
Scout	Scouts go on ahead to make sure there are no speed traps waiting for the rest of us.
Stalker	The stalker can be identified by their uncanny ability to stay in your blind spot. Even when you speed up or slow down, they stay right where they are. This can be especially frustrating when you need to merge into their lane.
Tailgating	This is a well known pattern where a driver follows very closely to the car ahead. The general rule of thumb is to leave 2 seconds of space between you and the car you are following.
Road Lord	When another driver appears to be attempting to change lanes in front of them, this driver will speed up to prevent them.

So next time you are stuck in traffic, try to spot as many patterns as you can. If you know of any patterns that I missed or have a better name for one of my patterns, leave a comment.

The illustrations in this post are courtesy of the GT Challenge arcade game and my wicked Paint.Net skillz :).

Ever notice that anyone going slower than you is an idiot, but anyone going faster is a maniac? - George Carlin

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.

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?

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.

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 :).

.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.

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.