This is a pair programming workstation at an undisclosed office near me... it has never been used. Note that there are no chairs... <sigh>

The mere fact that it exists at all does give me hope however. Agile here is not dead, only frozen in carbonite...

This station also sits in a shared workspace that is always empty. It's so sad when there really is a better way but nobody wants to use it.

If there were only two chairs here, with two programmers working together, then, "yer doin it RIGHT." If there were three more of these workstations with six other team members in this shared space, perhaps working with a couple of whiteboards and a cork board with story cards on it, then THAT'S where I want to be.

This station with its dual monitors, keyboards, and mice is the ideal pairing workstation. Both monitors have the same image (clone mode), and both keyboards and mice are active at the same time. The only complaint I would lodge here is that the workstation is so underpowered it really couldn't be used for development. The pair would have to use remote desktop to get to a development machine. Perhaps that is the actual design, however having the local machine there I think is much better.

"As a user, I can select my preferences and save them

so that the program will do the right thing."

ahem...

Sometimes we in the software business need to realize that the people using our software are not experts in the field. We must become experts at understanding the requirements and implications of the domain for which we write software, but we can not expect our users to do the same. We must be able to make some decisions with the software so that it does the "right thing" for the user. In today's world, software users have little time to fiddle with settings or options. They just need the software to do a job for them and do it the right way the first time. Our impatient "get it now" society of users definitely has this attitude. If our software doesn't do what they need it to do, they will more likely abandon it for something else before attempting to fiddle with settings, parameters, options, and preferences.

Our product owners need to be keenly aware of this attitude, and get the balance right with the features and stories that the customer base needs. While this is not an easy task, it is a very important one. As our software gets smarter and smarter, it should be more aware of what the user is attempting to accomplish, and it should make some decisions and assumptions based on the mode of intent. In addition (here is the key point missing from most software today) we need to *tell* the user what the mode is, and what the assumptions are. If we got it wrong, or the user wanted something else, then s/he has the opportunity to change the operating mode before the software attempts to do the "wrong" thing.

A "mode" could be an entire slate of preference settings, that come packaged out of the box with the defaults set for performing a specific task, or scenario. This entire slate could be modified if the user is advanced and cares to fiddle with them, but having the entire slate saved as a set, that could be chosen as a very simple selection. Then, always make it clear what the system operating mode is, and how to change it.

Keep it simple by being smart about what the user is trying to accomplish and make some decisions. Select the most appropriate mode, then - most importantly - communicate those decisions to the user, and let them know what the software is assuming about the task they are trying to perform. Give the user choices about how to control the software, and change its mode, but keep the goal to be helping the user stay more focused on performing the task at hand.