To the optimist, the glass is half full. To the pessimist its half empty. And to the engineer, the glass is twice the size it needs to be.

As an engineer, I love that joke. It gets right at the heart of why we as enginerds often have such a hard time communicating with real people.

However, it also reminds me just how demoralizing it can be to work with the pessimist.

Attitudes in software development

To Mr./Ms. Pessimism new ideas and new thinking are “yet another thing I have to learn”, rather than a chance to improve one’s self and challenge one’s own assumptions. If left unchecked, such negative attitudes can result in the team member sticking their head in the sand in hopes they can avoid learning anything at all.

The introduction of new or improved tooling is often met by the pessimist with the same resistance as new ideas and thinking. They “just don’t have time to learn another tool.” So, rather than capitalizing on the potential value that can be realized by reducing friction, automating repetitive/error prone tasks, etc… the tooling is dismissed as being too complex and having too high a learning curve.

The most costly effects of a negative attitude are realized in the pessimist’s reaction to change. For these folks change is all about perceived risk and the failure of the business to decide what they want, rather than being about an opportunity to provide value to the business. Missed opportunity costs, indeed!

Negativity devastates teams

But even with all of those missed opportunities, an individual’s negative outlook has the biggest and most devastating impact on the rest of the team.

Teams feed off of the energy and emotions of the rest of the team. As a result, even a single negative attitude will eventually spill over and impact others members of the team.

And though the attitudes of other team members may not spoil entirely, the negativity has begun to spread – and left alone it will continue to do so, eventually infecting the team as a whole. Negativity is a self-fulfilling prophecy and a team with a negative outlook is condemned to failure.

Team members with a negative attitude are thieves, robbing the team of its potential, its moral, and often its success.

Address negative attitudes early

I am by no means an expert in dealing with team dynamics nor questions of personal mental health, but in my experience its best to address negative attitudes as early as possible. Don’t let things fester and don’t stick your head in the sand hoping they’ll work them selves out.

The team as a whole needs to take ownership of itself. It needs to work as a unit to provide a positive environment that's open and adaptable to change. That encourages and fosters education. And most importantly, the team needs to continually seek to improve itself and the practice of software development.

Looking across blogs, Twitter, and the community in general there has been a lot of discussion around Microsoft's forthcoming Entity Framework.

In the midst of the discussion many valid criticisms have been drown out or lost in the noise of the cheerleading, trolling, and marketecture generated by community Gloryhounds, Redmond, and any number of other super-pro-Microsoft groups/identities. Even the alt.net community has been guilty of adding to the noise and confusion.

The noise has gotten so loud that the message itself has been lost.

Voice your concern

But through that noise it looks like a voice may finally be heard, or at least serve as a unifying call for others to follow, in the form of an open letter.

A number of people have worked on an open letter to Microsoft and the Entity Framework team. It outlines the various deficiencies in the EF specifically related to concepts a lot of us value as solid working practice. Every effort has been made to balance honesty with diplomacy and cooperation.

I would urge anyone who believes in the deficiencies outlined in the letter to sign the letter and then support the message. Blog it, Twitter it, discuss it, print it out and leave copies laying around your team room.

Remember, the goal of the letter is not to pull the plug on the Entity Framework, its to raise awareness among Microsoft customers as to the risks involved with adopting it.

Educate. Spread the message.

ADO .NET Entity Framework Vote of No Confidence.

A few weeks ago Oren (known to many as Ayende Rahien) pushed out a Rhino.Mocks beta drop so we could take a look at the new Arrange/Act/Assert syntax being cooked up for the pending 3.5 release. Yesterday I finally upgraded my client project to the 3.5 beta bits and started digging into the new syntax.

AAA, FTW!

After using Arrange/Act/Assert for just a day or two I’m already hooked. It feels like a much more natural fit for bdd-style tests.

The whole Given, Expect, When, Then, go-back-and-verify-expectations flow always felt clumsy and counterintuitive, and AAA allows for a more natural Given, When, Then, Verify Expectations.

If that doesn’t make a whole lot of sense, don’t worry… I’m planning a follow-up post to dive a bit deeper and hopefully illustrate the point. For now though, I’d encourage you to go take a look at the Rhino.Mocks tests to get a feel for what you can do with the AAA syntax.

Faster is better…

Aaron Jensen did some digging and was able to speed up performance by a pretty noticeable amount – nearly 50% according to his measurements.

And not that I don’t trust Aaron’s measuring abilities or something, but I decided to do some measuring of my own. I upgraded a current client project and I can confirm, these Rhinos are turbo-charged!

I ran our UnitTests project, which at the time had 1566 tests with none of hitting a database, external resource, etc…, but a majority of them do rely pretty heavily on mocks.

I wasn’t nearly as scientific as Aaron. In fact I was straight-up lazy, running the test project using the most handy mechanism at my disposal - TestDriven.net.

I did a few runs using Rhino.Mocks 3.4 (test runs #1 and 2 in the above picture) and then a couple more with 3.5 (runs #3 and 4). And my totally unscientific results showed… drum roll please… the new bits to be about 50% faster. Sweet!

Tired of typing all those underscores_while_writing_your_BDD_specifications? Yeah, I wasn’t really either. However I’ve heard read complaints from some folks that typing the underscore so many times was getting annoying, so they had opted for PascalCasing instead.

Just deal with it

Maybe its because of my exposure to Ruby and the joy that is RSpec, but I don’t think such minor annoyance is enough of a reason to top using a more readable style. Repetitive Stress Injury, be damned!

Or maybe not! The other day while cleaning out my RSS reader I came across AutoHotKey (thanks JP), a utility that allows you to launch custom scripts, macros, etc… via keyboard shortcuts.

No more Ctrl + -

Thanks to some great work by JP, Aaron Jensen, and David Tchepak we have an AutoHotKey script that can automagically replace any space characters with an underscore, as you type, in real time.

You can toggle the script on and off using the Ctrl + Shift + U hot key, a.k.a – keyboard shortcut. The script is also smart enough to turn itself off when you hit either Enter or Escape keys. And Aaron even has a version of the script that is only active when Visual Studio is active. However, being that I use e-Text Editor as my Ruby IDE, I like having the script available everywhere in the OS.

Dave added a little more sugar by tweaking the script so it shows a custom icon in the Windows task tray when the script is running, or not. A nice touch to really round out the experience.

Get yourself some AHK!

The one thing I found a little confusing was how exactly to get the script up and running, with the icons. Luckily, you won’t have to struggle… I’ll lay it out for ya’. :)

1. Get AutoHotKey – download and install it.
2. Grab JP’s script – or Aaron’s modified one if want. Save the script as some-name-here.ahk, wherever you want, I have mine in my Documents directory.
3. Pull down Dave’s icons – copy the two icon files to the same directory as your .ahk script from step 2.
4. Launch your script!

Enjoy!

This may seem like a completely obvious tip to some, and like a complete waste of time to others. But you know what? Its something that I've found extremely useful so I'm going to share it anyhow.

Hey, this is my blog and I can do what I want! :)

Update: I forgot to explain how to enable Highlight Current Line in the original post. I've now added instructions.

Highlight Current Line

This feature is not available in vanilla Visual Studio - its part of my favorite zero-friction productivity enhancer, ReSharper. I'm sure other productivity add-ins like CodeRush/Refactor! have something similar, but I don't know for sure. Maybe one of my friends can confirm... looking in your direction Dustin and/or Jay.

Anyhow, you can see it in action in the screen shot to the right.

Notice the slight variation in contrast between the standard background color and that of line #27. That's the highlighted current line.

The key for me not getting too much contrast between your standard background and the highlight color.

For a dark background you'll want a highlight that is just a few shades lighter, and for a light background you need a shade that is just a bit darker. The highlight should be obvious, but subtle. The point is not to distract your eye, but just to give it a visual cue.

OK... so?

So why exactly is this important, helpful, or even relevant? For two reasons:

1. It makes finding your cursor extremely easy when navigating through your code base, which is really important when moving at the lightning fast speeds made possible by ReSharper and keyboard shortcut-fu.
2. I like shiny things... and eye candy. And that's exactly what this is. :)

So how do I enable it?

First you need to turn the option on, and to do that you'll need ReSharper. So:

1. Install ReSharper, FTW!
2. In Visual Studio, open the ReSharper -> Options dialog.
3. Open the Editor section.
4. Check the "Highlight current line" option.

Next you need to set a custom highlight color, which you'll probably want to do because the default one is pretty ugly... and doesn't work well with dark themes. To do that:

1. In Visual Studio, open the Tools -> Options dialog.
2. Open the Environment -> Fonts and Colors section.
3. In the Display items list, find the ReSharper Current Line and set your custom color.

Or the easy way...

If you're interested, you can grab the color scheme seen above (a variation on VibrantInk) from the CodeIncubator project's code repository. You'll find it in the IDE-Settings directory under VisualStudio.

Well, there you have it. Another possibly pointless usability/productivity tip from my IDE to yours. Enjoy!

Interested in getting started with Test-Driven Development but not sure where to start? Fear not!

Get you some!

That's right, you can now get your TDD at the front desk of your local Crowne Plaza.

Wait... what do you mean its not that kind of TDD? I saw this sign in the hotel lobby during my recent trip to the West Michigan Day of .Net, I swear!

Tim and James saw it too, just ask 'em!

The recent series of Day of .Net events have been a bit atypical of most other Microsoft related conferences/events - at least historically speaking.

The biggest difference I've seen? The decreasing number of "Hurray for the latest golden hammer handed down by our Redmond overlords" sessions.

Instead, most sessions have focused on practices, principles, and tooling decidedly not driven nor delivered by Microsoft. They come from a more organic source - a community of developers seeking to continuously improve ourselves and our craft.

What community?

Some members of the community might gather under the ALT.NET banner, others might not, but we are all part of the same evolving community.

We as a larger development community are not where we need to be, we can always do better. Heck, that's the entire premise of continuous improvement and one reason The Developer Exchange Program makes so much sense. But we are making progress.

Spreading the goodness

And its not just the big events like the recent ALT.NET Open Spaces event in Seattle that are helping to educate and push us forward. Many similar conversations are happening across the community - the Day of .Net events are a great example of that.

If you've never been to one before I'd encourage you to hit the next one in your area.

Not one coming to a town near you...? Organize one!

What if you've been out to an event or two? Why stop now? And next time bring a co-worker or friend and share the love.

To have any chance of educating and pushing this thing out of our echo chamber and into the mainstream we need to get folks involved. Bring someone along and maybe suggest a few sessions they could attend - ideally somewhere outside their comfort zone. Who knows, maybe something will stick!

Visual Studio can be a tremendous resource hog, especially if you have a large solution and you're using a productivity add-in or two.

On my current project we're running VS 2008, we've got just under 20 projects in the solution, and several of us are using the ReSharper 4.0 EAP nightly builds to enhance our dev-fu. And you know what... we're restarting VS at least a half dozen times a day to work around a nasty exception we regularly encounter while trying to compile:

Not enough storage is available to complete this operation.

Not enough storage...?

Yep - storage. But you should read storage to mean memory... RAM that is.

After running for a while the Visual Studio process (found under devenv.exe in process explorer) maxes out its available memory and the above exception is thrown. The only way to reclaim the memory and successfully compile the solution is to restart the process. Bummer!

Maybe we should just upgrade our hardware, right?

I mean, with cost of processor cycles and RAM falling as fast as gas prices are rising, why not just spend a few bucks and make sure we're all running multi-core boxes with 4+ Gigabytes of memory and storage space to burn. Well guess what... we are.

All of the developers are running nice beefy machines with lots of RAM, super-fast processors, and we even have nice 21" wide screen DVI monitors. So this ain't no hardware problem.

Its a software problem.

I will admit, we are running a mix of 32-bit operating systems - mostly Vista with a handful of XP machines mixed in for the devs that roll that way. And Jeff Atwood has covered the missing RAM problem before, but even switching to a 64-bit OS wouldn't solve our problem. At least not entirely.

The problem is with Visual Studio. Being a 32-bit application its limited to just 2GB of virtual memory, even if its running in a 64-bit OS. At least, its limited to 2GB by default... but we can hack around change that.

The hack... err, solution.

The first thing to do is tell the OS to increase the amount user-mode memory from 2GB to 3GB. If you're running a 64-bit you can skip this step.

• for Windows XP: Backup the boot.ini file and then put the /3GB switch in your boot.ini. (more information on the /3GB option)
• for Vista: run the following from the Visual Studio command prompt (Brad Rutkowski has the full scoop):

     1:  BCDEDIT /Set IncreaseUserVa 3072

Then we have make Visual Studio large address aware.

1. Be sure to backup devenv.exe
2. Using the Visual Studio command prompt, navigate to C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\
3. execute the following command:

      1:  editbin /LARGEADDRESSAWARE devenv.exe

Finally we'll use the old Microsoft-fix-all - reboot the machine. Bounce that box!

Look at all that memory!

At this point Visual Studio should be allowed to consume up to 3GB of memory before throwing that ugly out of memory exception.

Just to show you I'm not lying, I grabbed a screen shot of my process explorer with devenv.exe process chewing up more than 2.5GB of memory. Sweet!

Note: even with our large solution and running the early, and memory-hungry, ReSharper bits, Visual Studio typically stays around or just above the 2GB mark. However it can spike up to 2.5+ GB while compiling, as show in this screen shot.

This week I was having a conversation with some fellow developers at the ALT.NET Open Spaces conference and an interesting topic came up. We were talking about vast amounts of time, mostly personal time, we spend trying to improve our skills and our craft. We spend time reading and writing blogs, books, mailing list messages, attending and giving talks, contributing to Open Source, and reading and writing code.

We spend a huge number of hours in the quest for continuous improvement.

Self-teaching is good

We all agreed that self-teaching is important and we do it because we enjoy it, but man does it take a lot of time. For many of us that means we sacrifice or compromise when it comes to time spent with families, friends, and other parts of our lives.

Why? Because we're thirsty for knowledge and we know that others are out there doing things differently, and possibly better. We hope that by learning from them we can improve ourselves and our craft in the larger sense.

After some war stories and one-uppers we realized something. It be great if we could spend more time working with, and learning from, each other... in person! Ideally resulting in less wasted time banging our heads into the keyboard and more time doing other life stuff.

Learning from each other is better

What if we could each spend a few days a quarter at another developer's job, pairing with and observing he and his team work. Just being able to experience someone else's take on Scrum/XP, BDD, etc... would be awesome. The potential for cross-pollination and exchange of ideas and practices is almost limitless.

And think about how much faster we could learn in person. With such an immediate and personal feedback loop we might just find ourselves with enough free time to try to regain some of those things we're giving up now.

I have no doubt that going to observe Scott Bellware's team in action for a few days - or even better, an entire iteration - would have resulted in me learning more about BDD and challenging more of my own, and hopefully some of their, thoughts and understandings than I got six months of going it alone. And that translates to fewer nights with in front of my computer until 3am, and more time for the rest of my life.

And what about you? Wouldn't you love to go hang with Jeremy Miller and see how he runs his teams and with any luck, have some of his ReSharper-fu rub off on you?

Or see just why Aaron Jensen and Jacob Lewallen (a.k.a.: the Eleutian guys) love that AutoMocking Container so much? And believe me, they are stupid-smart guys!

How much better a developer would you be if you could regularly observe another Agile team in action... in person.

Today I received an email informing me that I've received a Microsoft MVP Award in the ASP/ASP.NET category. Woot!

Yeah, I realize its a whole day after all of the other MVPs received their renewal notices and all new MVPs got their emails, but hey... better late than never!

Actually, it seems the joker that originally nominated me messed up my email address and as a result my notification email got lost in the ether. But they eventually fixed the glitch, I received the notification email, and Rob is still my homey.

So what exactly does it mean to be a Microsoft MVP?

Actually... I'm not really sure yet. But I do know it means I'll be traveling to Redmond in two weeks for the 2008 MVP Global Summit, so that's something! I also get to put that snazzy logo on my blog, and I do loves me some snazzy badges. :)

Seriously though, I really appreciate the honor and would like to thank Rob Conery for initially nominating me and Phil Haack for submitting a second nomination - likely causing the buffer overflow that resulted in me be awarded the MVP status.

No takesies backsies!