One of my favorite shows on TV these days is (don’t laugh) the show Property Virgins on HGTV. In it, an experienced Realtor walks first-time home buyers through the house selection and offer process.

A lot of times the “let’s watch a couple pick a house” type shows highlight the inexperience of the buyers. Buyers tend to focus on the wrong thing, like paint colors or light fixtures, and gloss over things that are hard to change, like room layout. But the best part of the show happens right at the beginning, in a brilliant move to reset the usually unrealistic buyer expectations.

At the beginning of the show, the host asks the buyers a few key questions to identify both their budgetary constraints as well as their aspects of a home they most value. It could be location, layout, lot size, etc. But the buyers always have some sort of dollar amount they won’t go over.

The next step the Realtor does is rather brilliant – they take the first-time home buyers to a house that meets all of their aspects for an ideal home. It has the perfect layout, the perfect location, all the amenities they want, in the right condition, at the right size and so on. The buyers inevitably love this home, at which point the Realtor asks the buyers to guess how much the home costs. Also inevitably, the buyers are pretty far off the actual price, and inevitably their ideal home is typically at least double, if not triple or quadruple the buyers’ budget.

And inevitably, the buyers have sticker shock!

Talking buyers off the ledge

This fantastic approach accomplishes two important goals:

• Convey what perfection costs
• Force a prioritization

The host is never mean about showing the expensive house, but instead presents it as something to aspire towards. This also resets in the buyer’s minds that every house they see from there on out is going to have some subset of their valued aspects.

But instead of discouraging the first time home buyers, this approach tends to force them to focus on what is most important to them in a house.

Resetting expectations

We often have clients that are first-time software buyers, or first-time-with-someone-who-knows-what-they-are-actually-doing software buyers. A lot of what we do in the initial part of the project is framing the project for success. We look at everything the client wants, talk about scope and budget, then reset expectations back down to an attainable level.

What we don’t want to see happen are those buyers that look at dozens or even hundreds of homes looking for that house that checks every single checkbox and comes in at their budget. That house might exist, or it might not, but a lot of time can be wasted searching and searching.

Constraints force prioritization and hard decisions. Having an experienced guide (like that Realtor host) ensures that the buyer understands what’s feasible for their budget, as well as the guiding hand on helping to share experience on what things matter (the electric wiring needs replacing) or do not (the bedroom has shag carpet).

Delivering value is really only half the equation. It’s up to us as developers to make sure the buyer understands what they are getting for their money (or time), relative to what’s out there in the market. If you bought a house in isolation, it’s hard to know whether you’re getting taken to the cleaners. But by having frames of reference (Product XYZ is similar to yours, and took ABC man hours/dollars to build), we can center the conversation around “what’s most valuable to me” instead of “how can we squeeze everything in”.

I love Git. It’s very powerful tool that lets me bend my repository to my will, with commands and features that blow the other source control providers I’ve used out of the water.

However, the tooling just doesn’t do it justice. From the download, installation, integration and CLI experience, it always feels like (in Windows land) that you’re playing in someone else’s back yard.

Over the next few posts, I’m going to compare the experience of using Git with that of Mercurial, who has, in my opinion, lesser features, but a much MUCH better experience.

The Mercurial download experience

Let’s look at searching and downloading the Mercurial client. When I google “Mercurial” or “Mercurial Windows” or “Mercurial Windows Download” or variants, two of the top results are the official Mercurial home page, or the official Windows client, TortoiseHg.

From there, I want to download Mercurial. Both websites offer very clear ways of doing so. The Mercurial site:

And the Tortoise Hg site:

Two very large “download buttons”. These buttons are interesting in that:

• They link directly to the file to be downloaded.
• They both link to the exact same installer
• They know what OS you’re using, and display the correct installer accordingly

TortoiseHg is the official Hg client for Windows, and includes:

• The command line interface
• Windows Explorer integration
• Visual tools (Workbench etc.)
• Visual Studio integration
• Merge tools

It’s a completely out-of-the box client that includes EVERYTHING that you might need to run Mercurial, all in one package, and consistently presented to the end user.

Next, let’s look at the Git download experience.

The Git download experience

When searching for Git downloads, you’re primarily directed to one of two sites – the official Git site, or the official Git tools site for Windows, hosted on Google Code (and also GitHub, curiously enough). The Git site is clean enough:

Except I have 3 download links instead of one. Not a big deal most of the time, but already choices are presented to the end user over the Mercurial site. Clicking on the Windows link takes me to this page:

Instead of linking me directly to the installer file to download immediately, I’m directed to the downloads page of the Google Code site, where I am presented with yet even more options. There is nothing in this screen that screams “THIS IS THE INSTALLER YOU WANT IGNORE THE OTHERS”. As someone new to Git, how do I know which to choose? Probably the first one, and most people would choose the first one, but presenting choices here is pointless and confusing.

Not to mention, I’m whisked away to a site that has nothing to do with the original Git site. The official Git site didn’t mention “msysgit” but now I’m on the msysgit Google Code site. Even more confusing is that the file has the name “preview” in it, and the installer is labeled as “Beta”. So is the right one or not? I might be inclined to search for the last “good” release and not a beta/preview one.

The Git installer is also less featured than the Mercurial one. The official Git Windows tools include:

• Windows Explorer integration (very limited)
• A CLI through the Git Bash or directly in a command prompt
• Visual tools (OK tools)

However, I typically don’t point folks to the official Git client. Instead, I point them to Git Extensions, a more fully featured toolset that includes:

• Windows Explorer integration
• Visual Studio integration
• Richer visual tools
• Bundled merge tool
• Bundled Git installer

This isn’t the official Git Windows client, so you basically have to know it exists to find it. Almost none of the online tutorials recommend it, even though it matches much more closely to what Mercurial provides out of the box.

Improving the Git download experience

In two easy steps:

• Have the official Windows client be as full featured as the Hg one. Could just start with Git Extensions and go from there.
• Copy the Mercurial website’s behavior

In short, prefer Simplicity over Choices. Have defaults, and obvious ways to get to the non-defaults.

Andreas Öhlund posted recently on the concept of the “transport message” in NServiceBus. One of the mistakes I often see (and made myself) was misunderstanding the boundary of the unit of work NServiceBus applies to messages, especially around sending multiple messages.

In many of our systems, we consume flat files from third party integration partners. We take these flat files and deserialize each line of the file into a distinct message, so we first tried to do something like this:

ProcessLineInFileMessage[] messages = ConvertFileToMessages(file);
Bus.Send(messages); // Sends all logical messages in 1 transport message

view raw MultipleMessagesBad.cs This Gist brought to you by GitHub.

The problem we hit was that the unit of work boundary in NServiceBus is around the transport message, not the logical message. In a file of a million lines, that’s a million logical messages bundled together into one single transport message, and one transaction boundary! We had assumed that the overload for sending multiple messages was simply a helper method that encapsulated a “foreach”. Well, no, it doesn’t. All the messages are wrapped in an envelope known as a “transport message”, and it’s the transport message that defines the unit of work boundary (since that’s the physical message sitting in the queue).

Needless to say, we saw database connection timeouts pretty much immediately. Instead, we modified our use of the bus to instead send one logical message per physical transport message, with our friend the “foreach”:

ProcessLineInFileMessage[] messages = ConvertFileToMessages(file);
foreach (var message in messages)    Bus.Send(message); // Send one logical message at a time

view raw MultipleMessagesGood.cs This Gist brought to you by GitHub.

So when would you use the overloads for sending multiple messages? I’m not sure, but I’ll update if I find out!

If you’re in the San Diego area tonight, I’ll be giving my talk on domain modeling. Details below:

http://www.sandiegodotnet.com/

I’ve been told that there is free pizza. If not, I might be able score some stale bagels from my hotel’s lobby, but no promises there.

Hope to see you there!

This year was my first to attend the bacon debauchery that is CodeMash. I had been suggested to go by pretty much everyone that I’ve met that has gone, and this year I was fortunate enough to be selected as a speaker.

My talk was on “Crafting Wicked Domain Models” that while was not recorded, all the slides and code can be found on my GitHub:

https://github.com/jbogard/presentations

Although that event wasn’t recorded, check out Claudio Lassala’s blog, where he recorded me doing the talk at the Houston Code Camp a couple months before.

A couple of folks came up to me afterwards telling me that they could never code/refactor in front of a Live Studio Audience. But, since the example was straight out of a real project I had lived through, it made going through the code a lot easier.

The questions afterwards were great, too. I always get some discussion around “it’s great and all, but now I have a bunch more classes to deal with”. It’s a fair criticism, and one to keep an eye out for. The way I see it, if the code is more understandable and more representative of real-world concepts, it’s a win. If, however, I’m having a hard time thinking of the names of classes for which I’m building responsibilities around, it’s a bit of a smell that I’m just inventing abstractions.

CodeMash really was a blast. The people were fantastic, the location was great, the food was fantastic, the beer and bacon were plentiful, and as always, the conversations were unforgettable. Hope to see everyone there next year!

My dislike of Flash has been well documented, so last month I thought I would try to see what the internet was like without Flash installed, whatsoever. I removed Flash completely from my system, including any Chrome plugin (Chrome has Flash built in).

I’ve never tried to simply go without Flash. I’ve used FlashBlock and AdBlock to block bad Flash, but for the most part, I couldn’t really tell what sites used Flash or not. I wanted to see how far I could go without Flash.

The final answer: not very far at all.

Three sets of websites were difficult or impossible to use:

• Restaurant websites (who for some reason are determined to make horrible, horrible sites)
• Video streaming sites (YouTube, Vimeo, and other media outlets)
• Some food product-related websites

I’d put “musical group website” in the list, but I don’t really visit those much. Sites like Tazo.com, while not a restaurant, rely wholly on Flash for the entire “experience”, offering no options whatsoever for non-Flash browsers (like my iPad and iPhone). The answer of course is not “OMG let’s put Flash on mobile devices!!!1”, but to stop making bad websites.

Other sites surprised me with their use of Flash. For example, GitHub uses Flash to perform its “Copy/Paste” code operations (which I guess is only possible/feasible with Flash). Gmail uses Flash for some more advanced file attachment controls, but at least has a fallback option.

Final verdict? It is not possible (yet) to use the internet without Flash. Which is unfortunate, because the bulk of my “browsing” these days is on the iPad. It’s so, so annoying to have to switch to a desktop to look up a restaurant’s hours. Unfortunate, and totally unnecessary.

Thankfully, Adobe is forcing the hands of web developers somewhat by discontinuing development of their mobile Flash platform. But we can all do our parts to help rid the world of Flash (for bad uses). If I ever run into a totally Flash-dependent website, I write an email to the webmaster, saying I’m a 56-year-old grandmother who can’t use their website on my iPad and that it’s totally ruined my evening.

In light of recent conversations around ActiveRecord and Rails, I thought it might be important to recognize the factors in a project success, in terms of the code produced:

In order for a software project to be successful, two things matter. What you code (the features you choose to develop) and how you code it (what technology you use, how easy it is to change, etc.)

These two constraints balance against each other, and neither is really more important than the other. If you code crap relative to what you need to code, then what you deliver won’t be good. However, it’s also important to recognize what drives what:

That is, what ever features/design/scope of what you’re building should drive the architecture/style/technology/patterns of how you code it. Picking the right before the left is putting the cart before the horse. Understand what you’re building, what the vectors of change will be, how large the application will be, how complex in which areas it will be, and let that drive your decisions on what framework/technology/patterns to use.

Once you know HOW to use a technology, the next step is to know WHEN to use that technology, and more importantly, when not to. Clients don’t care about code, but they do care about a bad product. Know what’s important here, and make sure that the code is merely the means (a very important means) to an end.

One of my favorite recent books I’ve read is the tome on human societies, “Guns, Germs, and Steel: The Fates of Human Societies”. In it, there is a section examining domesticable aminals. The author walks through the observation that although there are 148 big wild terrestrial herbivorous mammals, those that could potentially be domesticated, only 14 animals passed the test to actually become domesticated.

The reasons for failure of those other large mammals harks back to the first line of Anna Karenina:

Happy families are all alike; every unhappy family is unhappy in its own way.

While all 14 domesticated animals had common traits on why they were successful, each species that cannot be domesticated fails the test for some unique, specific reason. For example, zebras evidently have a nasty habit of biting people and not letting go.

Looking at software projects and the rates of failure in the industry, I think that there is a very similar phenomena: Successful projects all have common reasons for success; failed projects each fail in their own unique, spectacular way.

Duke Nukem and unlimited budgets

At a No Fluff Just Stuff conference a couple of years back, the keynote speaker shared a story about a failed project. He joined the project a couple of years into the development, and the team had yet to release anything to production. He went on to detail that he was on the project another year and a half, with no production release in sight, and left the project.

This project was one of those legacy re-writes, given pretty much unlimited budget and resources, in hopes that this would produce the best possible replacement for the existing product. The project had budget, resources, executive backing and visibility, technical leadership, support from domain experts etc. etc. Yet the project was still a colossal failure. Why? It never released!

Looking at the infamous story of Duke Nukem Forever, I get the same impression. Fresh of the success of Duke Nukem 3D, the software team set out to create the best 3D shooter on the market. This would of course take time and budget. Both of which the team had nearly unlimited resources for. But the technology kept changing and improving underneath their feet, like that line from Alice in Wonderland:

It takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!

Clearly something was missing on this project, but it wasn’t anything to do with resources. So what was missing?

Why projects succeed

Instead of looking at the myriad of reasons for why a project could fail (I always go back to the Classic Mistakes from Steve McConnell), how about we look at successful projects and determine what commonalities these have? If we look at the domesticated animals, they all must possess these six common characteristics:

• Diet
• Growth Rate
• Problems of Captive Breeding
• Nasty Disposition
• Tendency to Panic
• Social Structure

That is, if any candidate for domestication fails in one of the above categories, it can’t be domesticated.

So how can we distill the common project mistakes into a set of common characteristics? Since they’re grouped in specific categories, we can trace many of these back to specific root causes:

• Right people for the project needs
• Right budget to achieve the project goals
• Releasing early and often, or a deadline for delivery
• Constant introspection to improve delivery
• Alignment between the project sponsor, management, developers and other team members on project’s goals

If these look familiar, it’s because they pretty much make up the iron triangle of software development from Scott Ambler:

Going in to a project, the entire team from executives to developers need to agree on the parameters of the Scope, Resources, and Schedule, and constantly introspect to make sure that the team constantly improves its ability to deliver.

I know I’m probably missing something here, but it seems that all the other project mistakes seem to stem out of a deficiency around:

• Scope
• Resources
• Schedule
• Alignment
• Continuous Improvement

A project can succeed despite any of the Classic Mistakes, but lack of any of the above characteristics seems to doom a project to failure.