The highest voted and overly pedantic answer is, “it isn’t: cars themselves have software that is far more reliable than the mechanical parts of the car”. I guess that’s what you get when you leave it to programmers to answer such a question.

Maybe some software is reliable, but I bet you’ve used a custom software system that was far less reliable than your car, haven’t you? I know I have. I’ve built a few them in my past. I’ll take my Honda over some custom software systems any day!

Why is my custom software system so unreliable?

Of course, there are several answers, and I am a programmer, so can’t just answer this with a single sweeping generalization. The reason software can be unreliable is as complex as unreliable software is – and therein lies the answer!

At Headspring, we’re big fans of the book “The Mythical Man-Month” by Fred Brooks. It’s one of the most important and influential works on the human elements of software engineering. Even our sales and marketing folks have read it – ask them about it!

There are two passages in the Mythical Man-Month that I believe best answer this question.

Plan to throw one away

You don’t need to be a vehicle manufacturing expert to understand that to successfully build a new car, you need to go through multiple rounds of designing, prototyping, and testing. Early prototypes are “thrown away” each time until eventually the manufacturer has produced a car that meets all of the design, safety and performance goals. Your Camry is so reliable because it wasn’t the first thing Toyota bolted together.

Yet custom software is often treated differently. “Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built. …In most projects, the first system built is barely usable. It may be too slow, too big, awkward to user, or all three.” (Brooks, p.116) You’d never buy a car that was the first prototype out of the design shop, but I bet you’ve purchased or used software that is.

One reason the custom software system you use is less reliable than a car is because its creators likely never planned to throw one away. They delivered the throwaway product to you.

Complexity and maintenance difficulty

The other reason software can be unreliable is complexity and maintenance difficulty. “Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike. …software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.” (Brooks, p.182)

It may not seem like it, but in some ways software is orders of magnitude more complex than a car. The mechanics of a car engine are constrained by the physical world in ways that software is not. This complexity also makes it hard to maintain systems.

When a mechanic is changing your car’s oil, you can be confident he’s not introducing a defect in your windshield wipers. When you are repairing a flat, it’s unlikely that you’re going to inadvertently cause your radio to lose its station presets. Because software can be so complex, fixing it is far less reassuring: Brooks suggests that fixing a defect has a substantial (20-50%) chance of introducing another. (p.122)

Reliable custom software

If you have a custom software system that you don’t trust as much as your car, I wouldn’t be surprised. Software can be immensely complex and built in a way the nearly ensures a lack of reliability. And for every bug fixed, another one might be introduced. Custom software isn’t for the faint of heart.

At Headspring, reliable custom software is our specialty. We employ agile and test-driven development methods to mitigate the challenges of custom software development. Most importantly, we understand that our job isn’t just to build software, but to deliver satisfaction to our clients. A reliable system is worth little if it isn’t the right one for the job.

If you’ve been following along, you’ll have noticed that customizing Visual Studio in these ways is a bit cumbersome. Creating context menus are no better considering there are a ton of different menus depending on the context that you’ll have to independently configure.

Creating a right-click, Open in Notepad context menu

Lets start with a simple example: creating a new context menu to open the selected document in Notepad++ by using the external tool we previously created to open files in Notepad++. Here’s what we’re going to create:

Go to Tools > Customize, or right-click in the toolbar area and click “Customize…” to open the familiar customization dialog. Go to the “Commands” tab and select the radio button for Context menu and expand the drop down list. Brace yourself, because what you’ll see is every single context menu and sub-menu in Visual Studio. And herein lies the pain of creating a context menu – you have to configure it for each context it may need to be used in. You’ll see the menus are separated by the symbol “|” which denotes a sub-menu.

If you select “Project and Solution Context Menus” the “Controls:” list will show all of the context menus related to Projects and Solutions (a Project menu, Solution Folder menu, and so on). The Project menu is thus in the drop down list as “Project and Solution Context Menus | Project” and it has a controls and sub-menus itself. It’s a little confusing but once you poke around you’ll get the hang of it.

Above I have highlighted the “Project and Solution Context Menus | Item” menu, which is the context menu that appears when you right click a file in the solution explorer. Once this is selected, click “Add Command…” and find the external tool associated with the command you previously created in part 1. It will be in the “Tools” category. You can then click on “Modify Selection” and rename the command.

A final, optional step is to create a new “group” for you command(s). Select the command just under the one you added (“Open” in this case) and click “Modify Selection” on it and the “Begin a Group” selection will be available. Click it and a group separator will be created under your command:

You’re done! Close out all the dialogs and right click on a file in the solution explorer and it’ll open up in Notepad++ for editing.

Creating a context sub-menu

You can create a sub-menu much the same way. Select the menu it belongs in and instead of adding a command, click the “Add New Menu” button. You can rename it the same way you renamed your external command above. Once renamed and placed in the order you wish, it’s time to add commands to it. Because I just added a new menu to the “Project and Solution Context Menus | Item” menu, it will now appear in the context menu drop down list, and we have to select it there in order to add commands to it:

I’ve added the Explorer and Notepad++ commands that I created in part 1 in the “My Menu” I created. Now I have these commands available to files in the Solution Explorer in their own sub-menu!

Creating a custom toolbar

To create a custom toolbar, click Tools > Customize… or right-click in the open space in the toolbar area and select “Customize…” at the very bottom of this context menu. Click “New…” to create a new toolbar and give it a name and click OK, then close this dialog box.

It may appear that nothing has happened, but your toolbar has been added, it’s just empty. Look closely at your toolbars and you should be able to spot it:

Click on the arrow, then “Add or Remove Buttons” then “Customize”. From this dialog, click “Add Command…”. Here you’ll see two lists, one for categories and another for the commands associated with the selected category.  Find and select the “Tools” category, then select the “External Command 1” command.

The process is certainly a little cumbersome, but you’ll get the hang of it after doing it once or twice. The “External Commands” listed in the Commands window correspond with the external tools you have [previously configured –link to post #1]. It’s not magical enough to know the name of the external tools you’ve configured, so you’ll have to keep track of what you’ve created and the order they are in. In my example, I have three external tools configured, and I’m going to add each of them to my toolbar: External Command 1, External Command 2, and External Command 3.

When you are done, close out any remaining open dialogs and your custom toolbar should be all set!

I recently had to set up a couple of new computing environments so I went through my typical routine of setting up Explorer.exe as an external tool, and while doing so I pondered a few other tools that might be useful. In this and subsequent posts, I’ll describe how to set up some simple external tools, create a custom tool bar for them and even add them to the context menu.

In your menu, go to Tools > External Tools. You may already have some present like Dotfuscator or a Guid generator.

Setting up a tool is fairly simple: You can see above I have Windows Explorer configured with the /select argument to select the file based on the $(ItemPath) variable. More on this on MSDN – Arguments for External Tools. When you launch this tool it will open Explorer to the currently active/selected file (either in your editor or the one selected in your solution explorer). I find it a handy shortcut when I need to explore to a file deep within a solution.

Other External Tools

I recently added my other favorite editor, Notepad++, to my tools.  Instead of exploring to the currently active file, it will open it up in Notepad++ which is where I find myself editing project files, csv files and other documents that I don’t need to edit with Visual Studio. You can configure Notepad++ with:

Title: Notepad++ (or anything you wish)

Command: C:\Program Files (x86)\Notepad++\notepad++.exe (location of the exe)

Arguments: $(ItemPath)

At Headspring, we use the open-source Tarantino Project to deploy many of our applications. On some projects the deployer executable resides somewhere in a lib folder within the project which means you have to walk through at least a few directories to get to it. I recently made a batch file to launch it straight from the command line from the root of a project, and so I went ahead and turned this .bat file into an external tool while I was at it.

Title: Tarantino Deployer

Command: $(SolutionDir)..\Deploy.bat

Arguments: /min (this hides the cmd window)

The Deploy.bat file sites in the same folder as the .sln file does and simply points to the relative location of the deployer exe:

@echo off
Start /D.\lib\deployer\ .\lib\deployer\Tarantino.Deployer.exe

Launching External Tools

Once you’ve set up your tools in the dialog shown above, they will appear in your tools menu like so:

Stay tuned for more! In the next post I’ll walk you through making your own custom Visual Studio toolbar to contain your tools.

Part 2: Creating a custom toolbar

I’ve been reading “59 Seconds: Think a Little, Change a Lot” by Psychologist and author Richard Wiseman. The book contains a firehose of fascinating research studies and conclusions aimed to help change your life in under a minute. One passage goes on to detail how much of an impact greenery can have on your workplace productivity.

“An eight-month study of creativity in the workplace conducted by Robert Ulrich at Texas A&M University showed that adding flowers and plants to an office resulted in a 15 percent increase in ideas from male employees and more flexible solutions to problems from their female counterparts.”

Mr. Wiseman (what a name, huh?) goes on to discuss several other studies including one done by Andrew Elliot at the University of Rochester that compared creativity levels of people in rooms of different color, where green walls were a clear winner over red. If you don’t want to read the book, a quick Google search will yield a plentiful amount of information on the benefits of plants and the color green (like this one).

So now that you’re convinced, why does greenery  have such an effect? According to Wiseman, evolutionary psychologiests suggest that centuries ago when humans lived amid healthy trees and plants it resulted in a sense of comfort and calm because it meant food was nearby. And pleasant feelings make people more helpful, happy and creative. Hard to argue that.

Whatever the cause, several studies agree: a plant in your office would do you some good. Do you have plants in your office? Why or why not?

• GetGlimpse.com
• NuGet Package of the Week – Glimpse

There are several built-in plugins for Web Forms and MVC that will serve many needs, and you can even create your own. This tutorial will demonstrate how to create a plugin that will display the SQL generated by NHibernate.

Glimpse Plugins

Plugins are implemented by a simple class that implements the IGlimpsePlugin interface. There are a couple of great “hello world” example plugins on the Glimpse creating plugins page. Besides setting the name and some optional start-up code, a plugin’s main job is just to return some set of data that will be rendered to the Glimpse UI. What that data is and how we get it is the real magic, so read on below.

The actual code for this NHibernate Glimpse plugin is fairly simple. We create a header column, add a row indicating the number of SQL statements that were executed and then add all the actual SQL to the plugin data. The SqlLogger class referenced here is just a static class that acts as a wrapper for the HttpContext.Items collection, which is where we’re logging the SQL itself. You can find a full gist including this class and all of the following code snippets, with comments, here.

[Glimpse.Core.Extensibility.GlimpsePluginAttribute()]
public class NHGlimpsePlugin : IGlimpsePlugin
{
	public object GetData(HttpContextBase context)
	{
		var data = new List<object[]> { new[] { "Key", "Value" } };

		data.Add(new object[] { "*count*", SqlLogger.Count });

		foreach (var sqlString in SqlLogger.All())
		{
			data.Add(new object[] { "*sql*", sqlString });
		}

		return data;
	}

	public void SetupInit() { }

	public string Name { get { return "NHibernate"; } }
}

Logging the SQL generated by NHibernate

The easiest way to log the SQL generated by NHibernate so it can be pushed up to Glimpse is to create a custom Log4Net appender and configure it in the web.config. It’s as simple as creating a class that extends the AppenderSkeleton base class and implement the Append method, like so:

public class NHibernateQueryAppender : AppenderSkeleton
{
	protected override void Append(LoggingEvent loggingEvent)
	{
		SqlLogger.AddSql(loggingEvent.RenderedMessage);
	}
}

Wiring up the web.config:

<log4net>
	<appender name="GlimpseAppender" type="Headspring.Data.NHibernateQueryAppender, Headspring" />
	<logger name="NHibernate.SQL">
		<level value="DEBUG"/>
		<appender-ref ref="GlimpseAppender" />
	</logger>
</log4net>

The hard part

There is no hard part! We’re done! Drop this into an application that’s using NHibernate, enable Glimpse, click over to the new NHibernate tab, and wonder how you ever lived without this.

The complete source code with comments is available here.