Giving Mono to my Husband

Holy crossed-platforms, Batman! How did I not know about Mono, the free, open-source framework that will run .NET applications on Linux and Mac OS X?

Not to get too personal, but I'm part of a mixed marriage: I run Windows and develop primarily in C#; my husband runs OS X and is not (actively) a programmer. Through love and mutual respect, we make it work. But what we have so far not been able to make work is my writing handy utilities and toys that he can use on his laptop.

I learned about Mono in Rod Paddock's intro to the May/June issue of CoDe Magazine. Then I came home, had Jon install Mono on his Mac, and gave him a quick little console app I'd written in C#. It ran like a charm. A WinForms app with one button and a popup message also ran, looking distinctly X11-y.

This is super exciting for us. We've been talking about a card-game playtest simulator, to help with his creation of card games. (Jon posts one free board game a month and has a few upcoming commercial releases.) That process usually involves a significant investment in card stock and time with the paper cutter, just to see how hands of cards come together and move through the game. A simulator would help him to vet the first and maybe second drafts of the cards without printing them out. Now that I know I can build something he'll be easily able to run, it's time to start designing!

Organizing Ideas with Concept Maps

I love concept maps as a way of explaining a topic. (Here's an example, capturing what I learned at a KaizenConf session.) If you're a visual thinker, you'll definitely want to check this out. If you design UIs, this is also of interest.

The way I use concept maps most often is exploring and explaining a concept to myself. The act of drawing the map sorts my ideas visually, lets me hang new information off logical hooks, and gives me a picture to visualize when I want to recall the info later. (If you've talked with me about F# and watched where I gestured, you've seen that OO ended up on the left side of my map, and functional programming was right of center.)

CmapTools is a free software application that makes drawing maps intuitively easy—better than paper, because you can move concepts after you've fleshed out more of the landscape. And I have a strong preference for paper for brainstorming and thought-capturing, so that's saying something.

I like it not only as a tool, but also as an example of usability. It's so low-friction because you trigger actions (creating a concept, making a connection) right where you're already focused, in the work area, not in some menu at the top of the window. Click-and-drag from an existing concept to create a new concept and connect them; then type, click, type to enter the labels on the connection and the concept. I admire CmapTools for its non-noisy GUI—and of course I love it as a user because I can create a map fast enough to not lose the thread of my thoughts.

The example linked above is cool in another way: It's on a wiki where participants at KaizenConf are creating the conference proceedings. Once you go self-organizing, baby, you'll never look back.

Visible Sprint Status: Maybe Not Corkboards?

I'm thinking about ways to track the activity—the status... progress... stuff—that happens within a development sprint.

You could conceive a user story as moving through a series of phases (e.g., development, code review, testing, accepted). You might set up your Scrum task board using this paradigm, where you move an actual piece of paper between different columns on a corkboard. Some project-management software packages I've evaluated encourage a workflow of phases.

I wonder if there's a better way. At the user-story level, the idea of "passing through phases" seems Waterfall-ish, which always snags my attention because so few human endeavors are that linear. Phases lead you into some non-Agile patterns of thought, and they obfuscate the current health of the sprint.

Mike Cohn's task boards (with pictures!) divide into rows as well as columns. A row corresponds to a user story, and the tasks that compose that story move through the columns, which correspond to statuses. I'd previously missed (or forgotten) this distinction, and I thought the cards on the board were stories. I finally noticed the difference while drafting up this blog post, because I went looking for corroboration about the disadvantages of moving user stories through phases on your task board. What follows is an analysis of those disadvantages: non-Agile patterns and obfuscated sprint status.

By non-Agile patterns, I mean that columns on a board draw boundaries (literal and metaphorical) between collaborators. Do you intend to tell your testers that they can't think about a story until it lands in their column? Are you keeping your product owner from looking at a feature until all the code is built and blessed (and you've run out of time in the sprint)? Are you throwing code over the wall at people who might as well be in a different department?

"Heck no!" you cry. But doesn't a task board with indivisible user stories, sitting inertly in discrete statuses, imply that's what you're doing? Well, it could. And the metaphor subtly seeps into your thoughts and behavior, constraining your team's responsiveness, creativity, and collaboration.

How does a story-oriented task board obfuscate the status of your sprint? After all, it is tangible, visible, large-as-life where everybody can see it. But what is it telling you? Here are some challenges I've observed.

The pieces of paper representing user stories are the same physical size, but the effort required for different stories can vary dramatically. You glance at the board for a gut check, but you'll draw the wrong conclusion from lots of little stories (unnecessary worry) or few big stories (misplaced complacency). You could ameliorate this by making the pieces of paper represent component tasks instead of whole stories, but does a mere task move into the testing phase? Does your product owner evaluate a task? Can your customers use one? No, they need complete user stories. Once you've made the papers represent similar-sized chunks of work, the moving-through-phases metaphor gets in the way again.

Phases are liable to proliferate, until you want more columns than is practical for an actual corkboard. For any given phase, you might want to distinguish between "Ready to be picked up" and "In progress." Even if you're tracking virtually in a project-management tool, having too many phases is still annoying; you spend your time clicking dropdown lists instead of creating software. If you're in this mode, though, one solution for distinguishing between "ready" and "in-progress" is to write your name (or set the "Assigned To" field) on an item when you claim it.

Some items visit a phase more than once—like when a tester discovers a bug and gives the story back to a developer. (See that hand-off? That's the non-Agile-ness rearing its head again.) So when you see an item in the development column, is that its first trip through, meaning a lot of work remains, or a subsequent trip and it's nearly finished? You can't tell by looking at the board.

A communicative tracking tool would show you where bottlenecks or wasteful idleness is occurring. Using phases obfuscates this as well, because it implies that your testers aren't even looking at a user story until the coding is complete. (Can you call a piece of coding complete if it hasn't been tested or shown to the product owner? I'd say not. So read "complete" as a different word that represents "passed from the Development phase to the Testing phase.") But testers at the beginning of a sprint are creating test plans and collaborating with developers and product owners on the acceptance criteria; their "Testing" column looks empty, but they are in fact very busy with useful work. Someone outside the team might look at the board, conclude that the testers are idle, and be tempted to distract them with other tasks.

What a list. It's strange to me to write it. At my old job, my team had to have a virtual task list so that we could share it across continents. I was always jealous of the kids who got to have real live note cards on real live corkboards. Oh, how wistful I was, to have such an elegantly simple solution.

But now that I've used a task board, I can see its limitations, and I wonder about alternatives. I still want to cling to the belief that a tangible solution is better than a software tool, but I might have to let that go. Software is much better, for example, at turning points of information into a communicative picture. It is also better at searching, archiving, sharing with out-of-town stakeholders, and scaling.

The right solution will radiate information. It will clearly communicate whether the sprint is on track and likely to conclude successfully. It will alert you to lurking risks, so that the team can react and adapt proactively. It will tell a story about the sprint from which you can learn during your retrospective. These are the requirements by which I'm evaluating tracking techniques. The right method will show the heartbeat of the sprint.

Workstation Hack: Visual Studio on 2 monitors

Having two monitors is an obvious improvement to any development workstation, but are there tricks for really effectively using all that extra acreage? I learned a great strategy from a co-worker for a two-monitor setup for Microsoft Visual Studio.

Hack Summary
Maximize the editor on one screen, and pull out all the floating windows (Solution Explorer, Error List, etc.) onto the second screen—which is great until you want to look at your database or your wiki or your work-in-progress app while also typing code. (If you're typing in the editor, Visual Studio is in front, which means all those little windows are in front of any other app you want to look at while coding.) The solution is to set up some shortcut keys that switch you from "Sprawl across two screens" mode to "Pull everything into one screen, dock the little windows, and make the second monitor available for other stuff" mode, and back.

Export Two Sets of Window Settings
You can save Visual Studio settings (such as window layout) to a file, and later import that settings file. For this hack, we'll export two settings files (one for two-screen, sprawl mode; one for one-screen, compact mode). Then, we can switch from one mode to the other by importing the appropriate settings file.

Get your windows how you like them in one-screen mode. For example, my Solution Explorer is a docked pane on the right, unpinned so that it auto-hides; and so on, for the handy windows I want at my fingertips. So, set those up.

Go to Tools > Import and Export Settings... > select the radio button for Export > click Next > uncheck All Settings > expand General Settings > check Window Layouts > click Next. Name the file (e.g., OneScreen.vssettings) and give it a location. Click Finish.

Now set up your windows in two-screen mode. Unhide a window by hovering over it, pin it, right-click on its title bar, and pick Floating. Drag it where you want. This is the artistic phase.

As above, export those settings, with a different name (e.g., TwoScreens.vssettings).

Create Two Switcher Macros
Add a macro module in the Macros IDE (Tools > Macros > Macros IDE), and create two macros, one to import each settings file. Here's my module, called WindowsSettingsSwitcher, which gets my settings files from C:\VSSettings\.

Imports System.IO
Imports EnvDTE
Imports EnvDTE80
Imports System.Diagnostics

Public Module WindowsSettingsSwitcher
    Public Sub SwitchToWinLayoutTwoScreens()
        DTE.ExecuteCommand("Tools.ImportandExportSettings", "-import:C:\VSSettings\TwoScreens.vssettings")
    End Sub

    Public Sub SwitchToWinLayoutOneScreen()
        DTE.ExecuteCommand("Tools.ImportandExportSettings", "-import:C:\VSSettings\OneScreen.vssettings")
    End Sub
End Module

You can test the macros from the Macro Explorer by double-clicking their names.

Assign Shortcut Keys to the Macros
Create some shortcuts that execute those macros. Tools > Options > expand Environment > click Keyboard. In the "Show commands containing" box, enter some text that will find your macros, e.g., "switchtowin" if you used my names above. Highlight a macro, put your cursor in the "Press shortcut keys" box, and type your shortcut. (Mine are Ctrl+Alt+1 for one-screen, and Ctrl+Alt+2 for two-screen, since those weren't in use by anything else.) I left the "Use new shortcut in" set to "Global." Click OK.

At this point, you can use your shortcut keys to switch modes. I added them to my View menu, too, mostly to give me a visual reminder of the shortcuts.

Add Switcher Commands to the View Menu
Tools > Customize > Commands tab > select the "Macros" category. Click and drag your macro from the Commands list in the dialog up to your toolbar. When you hover over View, the View menu will appear, showing the insertion point for your new command. Drop it in place. Right-click on the command in its new location, click on the Name box, and edit that down to something helpful (e.g., "OneScreen"). Repeat to add the other macro. Close the Customize dialog.


With this hack, you can keep lots of useful Visual Studio bits visible (liberating you from relying on the mouse to hover over auto-hiding windows, and maximizing your editor window), but stow them away quickly when you need the second screen for something else.

So how 'bout you? What are your workstation hacks?

NAnt and LINQ - namespace error

"The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)"

I was getting this error when using a NAnt script to build a project I created in Visual Studio 2008. Turns out to be related to which .NET Framework is targeted, in this case.

Aside: If you are not using NAnt, and you're getting this error when you try to build, then make sure your project has a reference to the System.Core assembly. But if you use the defaults in Visual Studio 2008, then you already have this reference. My project would build through Visual Studio, but not through my NAnt script.

Here's the cause. I thought I should use the latest stable release, instead of the latest beta, so I downloaded NAnt 0.85. It supports multiple frameworks, and by default it targets the framework in use. You can point it to another using the -t command-line argument.

But NAnt 0.85 is aware of frameworks only up to 2.0. For LINQ, you need 3.5, and therefore you need NAnt 0.86 (in beta at the time of this writing). I kept 0.85 just in case, so my NAnt folder contains a folder for each version; they co-exist. I just changed the path in my nant.bat file to point it to 0.86-beta. And voilà.

Hope this helps. Yay, automated builds!