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!

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!

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 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.

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.

public class RavenDbMessageModule : IMessageModule
{
    private readonly IDocumentStore documentStore;

    [ThreadStatic]
    private static IDocumentSession currentSession;

    public static IDocumentSession CurrentSession
    {
        get { return currentSession; }
    }

    public RavenDbMessageModule(IDocumentStore documentStore)
    {
        this.documentStore = documentStore;
    }

    public void Init(ITransport transport, IServiceBus serviceBus)
    {
        transport.MessageArrived += TransportOnMessageArrived;
        transport.MessageProcessingCompleted += TransportOnMessageProcessingCompleted;
    }

    public void Stop(ITransport transport, IServiceBus serviceBus)
    {
        transport.MessageArrived -= TransportOnMessageArrived;
        transport.MessageProcessingCompleted -= TransportOnMessageProcessingCompleted;
    }

    private static void TransportOnMessageProcessingCompleted(CurrentMessageInformation currentMessageInformation, Exception exception)
    {
        if (currentSession != null)
        {
            if (exception == null)
                currentSession.SaveChanges();
            currentSession.Dispose();
        }
        currentSession = null;
    }

    private bool TransportOnMessageArrived(CurrentMessageInformation currentMessageInformation)
    {
        if (currentSession == null)
            currentSession = documentStore.OpenSession();
        return false;
    }
}

One of the things that really bothers me about an implementation like this is that intimate knowledge of the threading model of Rhino Service Bus is required to properly implement an IMessageModule implementation properly. The CurrentSession property is static, yet the IDocumentStore member is an instance field. Why does an implementer of a message module need to be concerned about lifecycle of its dependencies?

I don’t really think it should – lifecycle of a dependency should at most be the responsibility of the dependency itself. Or even better, the responsibility of the container. Dependencies shouldn’t care where they are used, because that knowledge would violate the whole “D” in SOLID.

Instead, I’d much rather see something like FubuMVC behaviors. Here’s one with NHibernate to have a session always part of a request there:

    public class SimpleUnitOfWorkBehaviour : IActionBehavior
    {
        readonly IFubuRequest _fubuRequest;
        readonly ISessionFactory _sessionFactory;
        ISession _session;

        public IActionBehavior InnerBehavior { get; set; }

        public SimpleUnitOfWorkBehaviour(ISessionFactory sessionFactory, 
                                                IFubuRequest fubuRequest)
        {
            _sessionFactory = sessionFactory;
            _fubuRequest = fubuRequest;
        }

Note that the behavior doesn’t care about the lifecycle of itself. That’s completely managed by the FubuMVC infrastructure, it’s completely unimportant to the implementor. Then when it comes time to actually create a session, it looks like:

        public void Invoke()
        {
            _fubuRequest.Set(new Lazy<ISession>(() => 
                                  _session ?? (_session = CreateTransactionalSession())));

In the code above, the behavior chain sets a contextual dependency on the IFubuRequest, which, through the magic of child and nested containers, ensures that subsequent behaviors in the execution pipeline have the correct injected ISession from NHibernate. Nowhere in this code do you see any sort of lifecycle management.

The most you see is things like Lazy and in code that uses the dependency, perhaps a lazy Func<T>. But these are only in place because consumers want to direct the scope, not lifecycle.

Lifecycle of dependencies is best served in the framework. Barring that, the container configuration. Consumers and dependencies do not need to change their design to accommodate the lifecycle constraints of the hosted environment. Pushing that into these pieces leaks the abstraction of the hosting environment.

I suspect that most experiences will be fine on Chrome, except for poorly designed websites who force you to browse information through Flash. For legitimate uses of Flash, like video streaming, I don’t really know who does or does not support Flash yet.

I’ll report back in a month with the results. Or less if you really can’t use the web without Flash anymore.

Someone asked which certificate would be the better choice on Twitter today: Microsoft Certified Professional or Certified Scrum Master. My answer was very simple: neither because they’re both utterly worthless.

That’s a very common answer to those looking at the point of view from those taking the exams as a means of proving they’ve learned something. In that light, things like Certified Scrum Master and Microsoft Certified Professional are useless. They don’t provide any indication whatsoever that the person holding the certification is able to actually apply those skills in the real world.

In fact, if someone comes to me using certification as a substitute for examples of experience, it pretty much guarantees that experience will be lacking but bravado will be abundant.

So if you’re wanting to use certifications as a means of learning – don’t, it’s a waste of time. If you’re wanting to use certifications as a means of gaining credibility – you can, but be aware that those that give you credibility because of a certification are likely clueless.

So do certifications hold no value?

No, there is value in some contexts. Clueless or not, sometimes the illusion of credibility from a certification is better than the alternative for some folks. For example, we often meet clients thinking they need Agile advice, but once we start talking to them, it becomes clear that we can help them in other ways.

However, a certification might be a foot-in-the-door to start a conversation that we would otherwise be eliminated. It’s not being disingenuous – it’s recognizing that we have to understand biases and work with them rather than pretend/hope they don’t exist.

Certifications, in some organizations, have currency beyond the illusion of expertise. This could be in the form of currency for promotions, or special deals with vendors (like the Microsoft Partner program was the last time I was involved with it).

Having a certification gets you points that puts you in “Gold” status that gets lower licensing fees. Basically, certification is a coupon for lower prices. It’s a sacrifice employees make for the good of the whole.

Otherwise, yes, don’t waste your time or money. Don’t worry about the worth of the certification, decide if the process of getting certified holds any value.

The steps are slightly altered so that the Commit happens before Send. If step 2 fails, step 3 never happens. I see a couple of problems with this approach, namely in that it assumes:

1. I have explicit control over when transactions happen
2. I want explicit control over when transactions happen

If #1 is true, I have to wonder if #2 is also desirable. In most cases I run into, I don’t want explicit control over transactions. I don’t want to think about them, or mess with them, or deal with them. I want these to just happen without me having to do any work.

I instead like the idea of a unit of work, or at the very least, a concept of required infrastructure for transaction management. Regardless of the host environment I’m working with, WCF, WPF, ASP.NET, NServiceBus etc., my day to day development takes on a picture like this:

Day to day, I’m living in the green section. I don’t want to “remember” to create transactions, deal with a pattern of saving, committing, rolling back etc. This should just be taken care of for me, through required infrastructure. One example is in Ayende’s example of the RavenController in MVC:

using System;
using System.Web.Mvc;
using Raven.Client;
using TekPub.Profiler.BackOffice.Tasks;

namespace TekPub.Profiler.BackOffice.Controllers
{
	public class RavenController : Controller
	{
		protected IDocumentSession documentSession;

		protected override void OnActionExecuting(ActionExecutingContext filterContext)
		{
			documentSession = MvcApplication.DocumentStore.OpenSession();
		}

		protected override void OnActionExecuted(ActionExecutedContext filterContext)
		{
			try
			{
				using(documentSession)
				{
					if(filterContext.Exception == null)
					{
						documentSession.SaveChanges();
						TaskExecuter.StartExecuting();
					}
				}
			}
			finally
			{
				TaskExecuter.Discard();
			}
		}
	}
}

On every request, a Raven session is opened, and everything saved at the end of the request. All developers have to do to make sure that transactions are used properly is simply inherit from this controller.

With every application framework I look at, one of the first items I put in is the concept of implicit contextual transactions. The scope of what code I’m working with naturally fits inside a transaction, so it’s not something I want to have to worry about.

If I have to remember to call Commit on a transaction every time I introduce new data manipulation code, that’s just something I’m going to forget to do. Instead, transactions and unit of work management should wrap around my normal application code, without me needing to do anything to manage it.

In the next post, I’ll look at various alternatives to messaging for doing something non-transactional like sending emails (or calling web services), and examine the benefits and drawbacks of each approach.

Often times, you’ll see some sort of process that needs to notify someone that the job is complete via email. It’ll look something like:

public void SomeServiceCall()
{
    DoSomeWorkHere();
    CreateSomeObjects();

    SaveToADatabase();

    var message = new MailMessage();
    var client = new SmtpClient();
    client.Send(message);
}

This is all fine and dandy, but the problem comes when something like this is executed inside a transaction. We expect that if the SomeServiceCall method is wrapped in a transaction, that the database save should roll back. But what about that email? It often won’t fail until the transaction commits, which is AFTER the email is sent:

In the picture above, we can see that the transaction only involves the database, but we can’t un-send our email.

What we need to do here is decouple the actual sending of an email with the message to indicate an email needs to be sent. Right now, we’re using a synchronous, non-transactional mechanism of sending an email. Instead, we just need to wrap that interaction point with an NServiceBus message:

public void SomeServiceCall()
{
    DoSomeWorkHere();
    CreateSomeObjects();

    SaveToADatabase();

    _bus.Send(new SendEmailMessage());
}

We’re using the NServiceBus bus to send a message that we want to send an email. The nice thing about this picture is that the sending of that NServiceBus message now participates in the transaction:

In the case of failure, that message never makes it over to my NServiceBus host. If it does succeed:

Then my message is delivered to the SMTP NServiceBus host, which will then interact with the SMTP server.

By decoupling the action of sending an email with the intention through an NServiceBus message, I can make sure that the email isn’t sent unless I successfully complete the transaction.

Another nice benefit here is that I was originally synchronously sending an email. With this architecture, if the SMTP server goes down, it doesn’t affect the ability of My Service to stay up. Instead, the durable messaging of MSMQ and NServiceBus reliability mechanisms ensures that I don’t lose the messages of sending those emails.