Thursday, June 24, 2010

Video: Ruby for .NET Developers (From the Norwegian Developers Conference)

My presentation at the Norwegian Developers Conference, "Ruby for .NET Developers" is available for viewing on Vimeo.

There's a bit of off-color humor in the talk for the sake of making a point about orthodoxy, and done specifically-so for the European audience that it was presented to. So, no offense intended! :)

View it here or open it on Vimeo's site for more viewing options.

Here's the description of the presentation:

After having spent many years coding in C#, and after having spent equally as much time in the C# language culture, Ruby seemed like a lot of bad ideas and heresy. In fact, much of Ruby is heretical to a C# or VB.NET mono–culture, but the productivity gains demonstrated by Ruby on Rails teams remains an unavoidable elephant in the room. This presentation looks at C# code examples side by side with some equivalent Ruby code and shines a little light on what it means to have either "ceremony" and "essence". It challenges the claims of static typing's effect on tooling to deliver "developer productivity". And finally, some examples of Ruby meta programming are given to demonstrate direct solutions to programming problems that would require much ado with restrictions in C# that don't end up doing much more than reducing the efficiency of software development efforts.

Ampersand GT

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at

Monday, June 21, 2010

Praise for the Norwegian Developers Conference - A Conference with Heart

Leaving the Norwegian Developers Conference after the last session of the last day, conference participants were bid a fond farewell at the door by Kjersti Sandberg.

I suppose it's not such a big deal to have people saying goodbye to participants as they leave, but in the case of the NDC, the person doing the goodbyes was the conference organizer herself.

There is a lot to say about the quality and value of a conference like the NDC, but if you trace the outward expressions of quality back to the source of the quality, you inevitably find yourself staring square in the face of leadership. It's Kjersti's leadership that makes the NDC an excellent conference - and in my case, one of the best and most rewarding conference experiences that I've ever had.

When you build something that you truly believe in, and when you have intentions to do something great and hold yourself to extremely high standards, that sense of ownership is palpable in every aspect of the work and of the product. The Norwegian Developers Conference in Oslo last week was an obvious expression of leadership, vision, and commitment.

I get the sense that being at the door, in person, to bid farewell to conference participants wasn't just the execution of good customer experience technique and strategy, but was a moment for Kjersti to enjoy the fulfillment of hard work and excellent execution. I can't remember a conference where the conference director was so deeply invested in her customers' experience that she was there in person to wish them well and to express her appreciation for their participation.

Anyone can fake these kinds of expressions of customer service, but it takes heart to do it and to make it clearly sincere and meaningful.

Kjersti wasn't at the door to wish NDC participants a good journey back home and through the next year because it's just smart, personable technique. She was there because it meant as much to her to enjoy the moment of personal and personable accomplishment as the experience of the NDC meant to the people who came to NDC. And it was definitely a moment of absolute pleasure for me to watch something quite rare: a true appreciation for customer experience reflecting a true investment in product and customer development.

Kjersti wasn't at the door with a big sign over her head letting people know that she is the person behind the NDC. She was there anonymously. She wasn't there for the show and the display, she was there because it means something for her to be there, and to say farewell in person. It wasn't about a demonstration of investment in customer, it was simply investment in truth incarnate. For me, it was probably the most endearing moment of a conference that overflowed with endearment.

There's much more to say about the people involved in making the Norwegian Developers Conference happen. I'd just like to say thanks to everyone at Kjersti's company, Program Utvikling, and to Anders Noras, Rune Grothaug, Henriette Holmen, Jakob Bradford, Thale Sandberg, and a host of people who had a role to play in making the NDC a memorable and rewarding human experience.

The most important thing about creating a good conference is crafting a space for ideas and perspectives to come together - especially conflicting ideas and perspectives - to learn what new ideas can come from the experience, and to form new, higher order ideas that resolve what we had previously assumed were ideas of irreconcilable difference. It takes courage and integrity to create a space to allow this to happen. The space itself is just a blank slate, it becomes a space of courage and integrity when it reflects these qualities that are already qualities of its leaders.

Two salient takeaways for myself from my experience at conferences in Scandinavia:

Firstly, Scandinavian conferences, like NDC, Oredev, and others, don't seem to allow the kind of mindless orthodoxy that is eroding integrity in many conferences in the United States. They encourage encounters of diversity that, while tense, inevitably lead to the greatest ideas of the future, and point the way to the next steps.

And secondly, the United States conference market is in desperate need of a practitioner-level conference like the kind I've experienced in Scandinavia - especially in the Microsoft community, where diversity is increasingly avoided and, in some cases, actively suppressed. My hope beyond hope is that we'll see one of these conferences on our shores soon, and that their influence will help to get the community focused on goals that are more important to society as a whole than they are to the imperatives of a particular player's interests.

Ampersand GT

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at

Monday, June 14, 2010

Ruby Meetup this Friday at the Norwegian Developers Conference

This Friday at the Norwegian Developers Conference, the growing community of .NET leaders, influencers, and developers who have been developing in Ruby and exploring Ruby are hosting a Ruby Meetup during the conference lunch break.

Learn about how Ruby makes software development pleasurable and fun, .NET development with IronRuby, why web developers love Rails, the Ruby ecosystem and community, and why so many C# developers are adding Ruby to their kit.

Join myself, Rob Conery, Shay Friedman, Anders Noras, Ben Hall, Aslak Hellesoy, and a host of others in an informal gathering of .NET experts and Ruby enthusiasts.

Also, check out the Ruby sessions at the conference! This year's NDC has 5 Ruby-focused sessions on the agenda. As Shay Friedman says, the conference is the first to acknowledge the importance of Ruby to the .NET community.

  • Ruby for .NET developers, Scott Bellware, 9am - 10am
  • IronRuby - A Brave New World for .NET, Ben Hall, 10:20am - 11:20am
  • Practical IronRuby, Shay Friedman, 9am - 10am
  • Riding IronRuby on Rails, Shay Friedman, 13:40pm - 14:40pm
  • Testing C# and ASP.NET Applications with Ruby, Ben Hall, 13:40pm - 14:40pm
See you at the NDC!

Ampersand GT

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at

Monday, June 07, 2010

No Domain-Driven Design in Rails?

The issue of why there is no Domain-Driven Design in Rails came up on the Herding Code podcast episode with Cory Foy and Will Green.

The inevitable question came up: Do Rails apps and developers take on less complex problems and therefore don't require Domain-Driven Design?

There's another question that we can ask which mirrors an observation I've heard form notable Domain-Driven Design (DDD) experts: Do .NET developers use Domain-Driven Design for problems that are far too simple to justify Domain-Driven Design? And... is the Domain-Driven Design used in .NET pop culture really Domain-Driven Design in fact, or is it a lighter Domain-Driven Design that leans mostly on the DDD pattern language and remains somewhat naive about DDD? If these questions are indeed valid questions, and if they're being asked by leading DDD practitioners, then is the question about Rails and DDD a question rooted in valid presumptions, or is it coming from a perspective that stands on shaky ground to begin with?

Here's an admittedly-provocative question: Do the .NET developers who are wondering whether Rails is for lessor apps (as evidenced by the absence of explicit Domain-Driven Design) actually have a firm grasp of what Domain-Driven Design is, or are they merely using a pattern language and suffering the self over-estimation that is far too common in technology orthodocracies?

I think there's a missing piece in the inquiry. We're failing to ask whether Domain-Driven Design can be accomplished with the Active Record pattern, or can it only be achieved with the Domain Model pattern?

Furthermore: Is the Active Record pattern the only model object pattern used in Rails apps?

Rails is often about the part of the app that often deals with user interaction, or more specifically: user agent interaction. Do you need to use Domain-Driven Design for this part of your app? Maybe you do. Maybe you already do. Maybe you already use Domain-Driven Design for this part of your app but you're not yet aware that you're only using the DDD pattern language to name archetypes and layer supertypes in your design. After all, it's not like there's a lack of precedent for this in .NET apps "using" Domain-Driven Design. It might even be the most common form of DDD in .NET.

One of the most salient teachings to come away from Domain-Driven Design with is Partitioning - conceptual, physical, and logical. Partitioning is reflected in Domain-Driven Design's Aggregate Root pattern, its Repository Pattern, and its Bounded Context pattern, amongst others. The increasing attention given to eventual consistency and Command-Query Responsibility Separation (CQRS) in context of Domain-Driven Design also reflects partitioning and its effects and considerations.

Rails' - the framework - has absolutely nothing to say about partitioning. And its not supposed to. Partitioning is about a solution's topology and architecture. Rails is about building the user-interactive strata of an app. What you do behind the scenes is entirely out of Rails' hands. Rails itself - including its models - are a descriptive DSL over the abstractions that are over the infrastructure. You can make Rails archetypes as loosely or tightly coupled as you want (although you might be taking the Rails part of your app in the wrong architectural direction if you pursue extensive schema de-coupling, and you might need to be a pretty solid Rails hacker to do so).

That said, the Rails ecosystem has built a plethora of plugins for the framework that allow these architectural styles to be accommodated in a solution where Rails is in-play. In the wild, partitioning is one of the most obvious aspects of solutions that are front-ended by Rails.

Large-scale apps like Shopify, Gowalla, GitHub, Hulu, Scribd, Highrise, Yellow Pages, etc, don't get built without partitioning, and separating write from read operations. And you can't build a Rails app without modeling - whether you do modeling in your head, in code, or with diagrams (all are supported, bu the way). You can't build any of the non-public line of business Rails apps being built by organizations like Amazon, Electronic Arts, IBM, JP Morgan, NASA, Yahoo, Rackspace and a host of others, without tackling complexity at the heart of software design, and doing so in a way that insulates the non-complex part of your app with the complex part of your app, and dealing with them on their own terms without one tripping all over the other.

So, is the Active Record pattern sufficient for building Domain-Driven Design apps? Again, it goes back to how much you feel you should drive the whole topology and architecture of your whole solution from a framework that is intended to serve one aspect of solution architecture.

Domain-Driven Design is often trivialized to being merely a ubiquitous language (which is yet another DDD concept that itself is often trivialized into a meaninglessness that ignores other DDD precepts), entity classes, repository classes, service classes, and specification classes, and a smattering of other often-obscured concepts in the DDD heritage.

There's still something to learn from this form of DDD, but let's get serious for a moment: it's often just DDD as a pattern language, or "DDD Light" (now with 90% less real complexity!).

The average .NET app using Domain-Driven Design could, in my experience, be done for much less if done in the Rails ecosystem. Apps that use DDD inappropriately sometimes even end up needing more DDD because developers and designers have added insurmountable accidental complexity. There's nothing that contradicts DDD's essential message more than adding complexity to a solution!

Active Record, Rails, and Ruby, used in the parts of an app where its appropriate, don't contradict DDD. Without any question, it absolutely will change the pattern language used to describe the part of the app where you use Rails - but usually, that's all it does. If all you can see of Domain-Driven Design, however, is the pattern language, then you likely won't be able to use Domain-Driven Design even when you believe that you are using it.

There's little need for a Repository archetype in Rails. That said, Rails apps often do exhibit the essence of the repository pattern in the resource-oriented idioms (Aggregate Root, Repository, Specification, Context, Contours) that are ubiquitous in the Rails developer and architecture culture. Do you need to have a Repository class in order to be responsible about partitioning and to provide collection-oriented semantics for aggregate root access? For that matter, can you build a Domain-Driven Design app in programming language that doesn't have any notion of what a "class" is? If you can't have a Repository class can you still do Domain-Driven Design?

Do you ever hang data access operations off of a Repository class that aren't consistent with Repository or Aggregate Root semantics? Ever pull a lazy-loaded instance of Product from an OrderItem instance without going through a Product Repository? The question here isn't whether you've violated DDD in this case, but whether DDD's necessary constraints serve you well in these situations, and whether you should be trying to impose these constraints on this particular part of the whole architecture.

In my experience, there's as much Domain-Driven Design happening in the Rails world as in the .NET world. The big difference is that in the Rails world there's no social capital to be gained by speaking in the DDD pattern language in social gatherings of programmers trying to make their way in the professional world. Rails developers tend to just point to the game-changing web innovations and properties they've built and leave it at that.

One last thing about Domain-Driven Design and .NET: .NET developers tend to not recognize that using DDD as a pattern language is in essence a way to have an elaborated pattern language for Dependency Injection, as the design archetypes borrowed from DDD are usually either layer supertypes or archetypes of injected dependencies in static languages.

DDD Light is a side-effect of a programming paradigm where composition can largely only be achieved through Class-Oriented Programming. When the paradigm changes, and composition is something that the language itself can do, the propensity for DDD Light tends to dissipate. And that is why you tend to have less explicit mention of DDD in Rails' culture. DDD Light is as necessary in Rails as explicit, class-oriented composition and static dependency injection is. That's to say: it isn't (always). This was another topic briefly touched on by the Herding Code episode.

The necessity for Domain-Driven Design in fact and in practice in Rails is already well-established. Rails folks are just less-interested in talking about it in DDD terms, and not at all interested in DDD Light, as it's orthogonal to the paradigm - both socially and technically.

Rails - the culture and ecosystem - doesn't do DDD Light as the .NET culture and ecosystem does. That's about all we can really say about Rails and DDD.

Ampersand GT

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at