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

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

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.

Thursday
  • Ruby for .NET developers, Scott Bellware, 9am - 10am
  • IronRuby - A Brave New World for .NET, Ben Hall, 10:20am - 11:20am
Friday
  • 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 ampgt.com

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

Tuesday, April 20, 2010

Monospace: .NET Open Source Social at the Norwegian Developers Conference


Monospace

I'm very excited to be working with the folks at the Norwegian Developers Conference (NDC) in Oslo from June 16th to 18th on a very special event.

On Wednesday evening, June 16th, we'll be celebrating open source software in the .NET space with members of the Mono Project as well as NDC speakers and attendees from the .NET open source community, and the open source curious. Cap off your day with complimentary refreshments and a look at some of the community projects that have changed the face of .NET.

Did you know that you can run .NET applications on iPhone and Android using the Mono Project's open source implementation of the .NET stack? Mono will also let you run your apps in powerful and mature cloud platforms like Amazon EC2 and build for special purpose hardware platforms. Want to deploy your apps to Linux and Mac? No problem, that's what Mono does for you. Use your C# skills to go further than you ever thought possible, and you don't even have to leave Visual Studio!

Not only has the open source community made cross-platform .NET development a reality for all .NET developers, but open source provides a wealth of development tools that have become the leading indicator and the gold standard for where .NET software development is heading. Unit testing, ORM, build scripts, UI testing, MVC, continuous integration, source control... all of these fields were led by open source efforts years before they started showing up in commercial products. Stop waiting to find out where .NET development is going! Come to Monospace and greet the future right here in the present!

If you don't have any experience with open source, join the party and see what the fuss is about. Learn about the wealth of tools available to you as a .NET developer, made available by some of the most accomplished and expert developers in the community. Get your questions answered by the pros, and get tips on how to augment your projects and your skills with the vast array of mature, stable, open source tools and products. This event is for you. You don't have to be an open source hacker to enjoy Monospace. Stick around and indulge your curiosity!

If you're an open source user, add your voice to the conversation. There will be plenty of .NET developers with questions to answer and experiences to share. Participate in discussions and demonstrations and even get a chance to learn about projects that you haven't heard of yet. Bring your laptop and sit down with open source contributors and users for a little hacking and show and tell!

Join Jackson Harper of the Mono Project, as well as myself, and many of the NDC speakers and attendees for a fun night of sharing and networking at the Monospace social.

Check out this list of NDC people who are open sourcers: Rob Conery, Scott Allen, Ben Hall, Roy Osherove, James Gregory, Greg Young, Jon Skeet, Robert C. Martin, Michael Feathers, Louis Dejardin, Sebastien Lambla, Shay Friedman, Anders NorĂ¥s, Kevlin Henney, Lisa Crispin, Richard Campbell. And that's just a partial list! Come out to Monospace and find out what attracts these leading thinkers and practitioners to open source solutions.

Expand your .NET horizons at the Monospace social at the Norwegian Developers Conference. Information, links, and more at: Monospace.us

Also, checkout the NDC conference agenda for great sessions on Mono and .NET open source at: www.ndc2010.no

Norwegian Developers Conference

Many thanks to the Norwegian Developers Conference for supporting and sponsoring the Monospace social, and for making it happen.

See you there!

Thursday, April 15, 2010

IronRuby Drops - Does it Make a Sound?

Phil Haack, Program Manager for ASP .NET MVC commented:
"IronRuby RTMs!? Put that in your pipe and smoke it @Bellware. The asymptote has collapsed!" (original tweet)
I quipped with Phil when he was in Austin a while ago that, "IronRuby is asymptotic to shipping", which is the inside joke he's referring to. The point being that IronRuby has taken long enough to ship that it's dangerously close to that point of a multi-year software project where it may not be able to cross the last mile.

IronRuby has indeed crossed the last mile, and on April 12th, Jimmy Schementi and team announced the availability of IronRuby 1.0.

A hearty congratulations to the IronRuby and DLR team for getting IronRuby done, and to John Lam for getting the ball rolling with his RubyCLR project in 2006. It's a great accomplishment and another feather in the cap for the ever expanding diaspora of Ruby implementations, and most definitely a giant leap forward for .NET development and programming.

Enter ASP .NET MVC and the Loss of an IronRuby Vanguard

The furor surrounding Ruby isn't now what it was three years ago when IronRuby was announced. In the .NET community, the attention given to Ruby on Rails two and three years ago has largely subsided. The audience has had its attention redirected to ASP .NET MVC. Ultimately, I see this as a loss not only for IronRuby, but arguably also for the community.

There are a lot of newly-minted MVC developers in the web development community of .NET developers. I'm skeptical about comparisons made between ASP .NET MVC and Ruby on Rails by folks in the .NET community who haven't shipped a Rails project. These comparisons are often shallow and uninformed by experience. They're also not peer comparisons, and tend to point out things that one framework has that the other doesn't without consideration of whether these features are useful in both paradigms (yes, I sometimes use view models in Rails, I just don't require their signatures to be frozen before runtime so that static analysis tools have an easier job of it).

The ALT.NET community would have been the audience that was best-prepared to perceive and leverage the power of Rails, arguably via IronRuby, but instead it led the vanguard into ASP .NET MVC.

There is a tremendous wealth of uses for IronRuby but Rails has been the usual gateway to broader adoption of Ruby. With the Alpha Geek's attention redirected to ASP .NET MVC, the gateway isn't being crossed by the .NET intelligencia the way that it was by the Java community intelligencia that was ALT.NET's most influential inspiration.

For folks like myself who've invested enough effort to understand why some of our most respected teachers moved from Java for web application delivery to Ruby and Rails, there's no meaningful comparison of ASP .NET MVC to Rails.

While ASP .NET MVC has made significant progress in the past two years, it progresses at a snail's pace. We can contrast ASP .NET MVC's technology to Rails' technology, but this is the typical mistake that .NET developers make when trying to compare ASP .NET MVC to Rails because ASP .NET MVC doesn't have a whole ecosystem on the magnitude of the Rails ecosystem. This ecosystem includes not only the core framework technology itself, but the vast number and quality of plugins and packages for Rails (including those built for general Ruby development), the integrations with value-add services for both web businesses and web infrastructure, the vast array of hosting options and architectures, and the brain trust residing in the Ruby and Rails community.

Through a few years of working in Rails, I've come to a deeper understanding of Ruby (but I'm still no expert). And through this experience I've come to look at my own previous feelings about C# and static programming as a little shallow. It doesn't in fact amount to a personal preference, as many monocultural programmers have suggested to me. It's a matter of rational analysis and a willingness to accept the results of that analysis even of it contradicts my strongest feelings, my current preferences, and creature comforts.

After working with Ruby for some time, it started to become absurd to me to continue to build dynamic, adaptable systems with languages that aren't a great fit for this kind of work. I began to see that static design patterns were inevitably a mostly-wasteful workaround for trying to implement composable designs with languages that are hostile to this goal. I came to see that I was personally stimulated by the efforts to solve these dynamic programming problems with static languages. And I came to see that I wasn't being paid to put myself in the way of interesting but non-essential puzzles just to have a chance to solve them. There are other problems to solve - productivity problems, most notably, and business problems.

To me, this meant facing a hard inevitability: the de-emphasizing of a skillset that I had worked years to acquire, and a commitment to re-learning. The payoff, I knew, would be a reward in greater productivity and elevated conscious awareness.

I'm still learning, but there are many things that I have already learned in the past three years. One of the most important things that I have learned is that solving dynamic programming problems with static programming languages - while stimulating - is counter-productive except as a performance optimization. And even at that, I might consider alternative solutions, as GitHub, Twitter, and others have done in exploring high-performance, message-based, actor model functional languages like Erlang, a technology underlying new orders of performance technologies like CouchDB and RabbitMQ.

Most of all, I learned that even some of the most progressive .NET developers - even in today's ALT.NET community - are driven by a trepidation over a programming life without Visual Studio, and by association, ReSharper.

I've cautioned for sometime that there's a disturbing tendency toward what I've called "ReSharper-Driven Development". Far too many developers don't find anything wrong with saying, "I won't consider developing without ReSharper". I'd rather hear developers say, "I won't consider letting anything get in the way of my discovery of sources and paradigms of productivity and effectiveness that I simply haven't considered or can't conceive of yet".

I've got nothing against ReSharper, Visual Studio, or any other advanced development workbench (like RubyMine, for example). I was in the first wave adopters of ReSharper, and I was the first member of the community to have sponsorship from JetBrains for ReSharper. I was also a user of its predecessor, C# Refactory, going back to Visual Studio 2003. Nonetheless, I'm also willing to use a much more light-weight editor like TextMate or MonoDevelop. After twenty-some years of playing guitar, I'm also willing to pick up any guitar I can get my hands on just to have an experience of it, knowing that I'll be enriched by the diversity of the experience, and to know that this diversity is the foundation of my ability to continue learning at a pace that matters and to counteract the human tendency toward intellectual contraction and conservatism that is the inevitable side-effect of long-term, focused experience.

ALT.NET without the "ALT"

Some time in late 2007 I proposed "Integrity, Courage, Diversity" as ALT.NET's credo and motto. It didn't go too far and I didn't pursue it. It wouldn't be too long afterward that I'd realize that community leaders with great influence would begin to make exceptions for themselves in entitlements to using ALT.NET not for community service, but to justify efforts in celebrity-seeking as conveniently-beneficial to the greater good. ALT.NET became a launching pad for yet-another-BDD-or-MVC-clone-framework in the .NET space, as well as a way to secure increasingly more high-profile public appearances.

I didn't agree with David Laribee when he turned his attentions to means to "monetize ALT.NET". ALT.NET had barely established an unshakable foundation in diversity, courage, and integrity and had ultimately begun to come under attack from a myriad parties who wanted it bent to promote this or that bid for materialistic entitlement. It was like watching those parents who are willing to take their toddlers to auditions for movies, commercials, and pageants before the children had become self-actualized in their own sense of integrity. It was too soon. As clear as this was to me then, it's painfully and crystal clear now.

I don't agree with Jeremy Miller, creator of the .NET MVC framework, FubuMVC, who has suggested that .NET has now matured enough be as satisfying as Ruby and Rails. I think that this is only true from a place in life where we're driven unconsciously by the pleasure of solving static programming patterns problems.

I don't agree with Chad Myers who has implied that FubuMVC has advantages that Rails doesn't, without considering paradigm differences in working with Rails that may negate the value of things that may be advantages to static language pattern development.

I took heat from ALT.NET community members when I founded the ALT.NET Summit in 2007, introducing the .NET community to Open Space, and pushing a meme beyond the tipping point that within a couple of months of Dave's coining of ALT.NET had already started to fade into the typical background noise of fleeting fads. I took heat for building the conference website in Rails, stopping an on-going project to build the site on MonoRail after reviewing the site's code written in C# and realizing that the Rails equivalent would be much more elegant and less frustrating to deal with the torrent of frequent updates that hit a conference website in the weeks leading up to the event.

I have a profound respect for Dave having followed suit, building the altdotnet.org website on Rails rather than .NET, learning from experience, and making decisions informed not only by unconscious attachment, but also by experience shipping a project on a technology. I also think it's laudable that Dave's blog is built on WordPress, demonstrating that working with .NET doesn't require you to publish on CommunityServer, and that there are best-of-breed solutions outside of .NET monoculture that are preferable - whether they stimulate your current creature comforts or not.

ALT.NET was founded as a movement, even though the movement has been all but cleansed from the ALT.NET culture and history. In the redacted quote of Dave's original communication of ALT.NET to the community that holds a prominent position in the altnetpedia website, the following quote from Emerson is conspicuously absent: "there are always two parties; the establishment and the movement". Dave goes on to say, "If you’re ALT.NET, you’re in the movement. You’re shaking out the innovation. When the movement fails, stalls, or needs improving you’re there starting/finding/supporting that next leap forward."

Today's representation of ALT.NET stands in stark contrast to what people like myself had invested years of work in studying, practicing, teaching, traveling, meeting across the aisle, negotiating, volunteering, community organization, activism, lobbying, protesting, triumphing, sometimes losing, constantly sustaining and persisting in the face of an entrenched entitled cast of Microsoft community characters, and not just a small amount of personal sacrifice to build.

And while Jeremy has gone to great lengths to misrepresent the many years of dedication as a "holy crusade" and thus make it unpalatable for members of the ALT.NET community to expect the same commitment of themselves and thus of the community leaders that have not abandoned what ALT.NET had become, ALT.NET's diversity, integrity, and courage continues to become increasingly irrelevant considerations for the community.

And as diversity continues to erode, and mediocrity continues to accrete in mainstream .NET, so it does in ALT.NET as ALT.NET becomes the same kind of cultural body as the mainstream that it had intended to provide an alternative for. While ALT.NET adopts the exact same social mechanics as the mainstream entrenchment in serving the celebrity-seeking entitlements, great advances like IronRuby fall by the wayside if they represent inconvenient truths to what is now an ALT.NET establishment.

An Alternative to the Alternative

If the ALT.NET community continues down the path of fear into the exact same kind of tool-driven development behaviors that it criticizes Workflow Foundation and Entity Framework users for, it will undoubtedly miss the incredible opportunity that IronRuby lays at its feet.

ASP .NET MVC is not a peer to Rails. Not by a long shot. C#, even with the dynamic keyword, named parameters, and extension methods, is not a compositional language like Ruby. There is more power in this framework, language, and ecosystem than .NET developers - be they mainstream, ALT.NET, or progressives - may have had the occasion to understand.

If you value your experiences with MVC, then you might value the works that ASP .NET MVC has attempted to interpret, largely creating a low-fidelity facsimile that is generations behind the originals. If you're a patterns developer, an agilist, a test-driver, and an amateur of forward-thinking, no-limits technology communities, then the Ruby community - to my eyes - has more to offer you than what has become of ALT.NET in its present incarnation.

You don't have to leave .NET and Windows to experience Rails and Ruby as many notable .NET influencers have - although, like them, you might decide that .NET and Windows are unnecessary to building great web products. Nonetheless, now you have a choice.

You also have a choice to continue to have your attentions re-directed to lessor solutions. But understand that now that IronRuby has dropped, you're choosing lessor .NET solutions. And while it might be understandable that you aren't comfortable with anything other than Windows, you can experience Rails on IronRuby and use IIS as your application server.

And best of all, in the original spirit of ALT.NET, you will have a universe of alternatives available to you if you choose to take advantage of them. Alternatives that include:
  • Immediate support for RESTful design and resource-oriented MVC
  • A more mature and fully-featured routing engine including route helpers
  • A better plugin model with orders of magnitude more available plugins and service integrations
  • A package distribution system right now with Ruby Gems
  • Hosting in the cloud without constraints using platforms like Amazon EC2, Rackspace, Engine Yard
  • Managed cloud fabric like Heroku if the bare-metal cloud doesn't suit you
  • More mature client libraries for emerging high performance storage, caching, application server, and middleware technologies
  • Being in a social and business community that builds game-changing products and services like Hulu, GitHub, and Twitter
  • Participating in the community that is making the greatest advances in TDD and testing tools and methodology
  • And best of all: being able to look back a year from now and realizing all that you've learned about what you thought you knew :)

Resistance

You're going to face resistance and maybe even vilification in some cases in the .NET community if you make such a move. If you value the courage that progressive software development is all about, you'll weather the storm and build character in the process.

If the ALT.NET community had stayed on-target with Ruby and IronRuby, there would be a good number of popular bloggers who might loose their audience. You're not in this profession to provide those with a sense of ongoing entitlement to a perpetual audience with even more entitlements. It's not your job to sit at the feet of static pattern puzzle-solving masters in a time when the necessity of those puzzles is simply no longer an absolute.

There are a whole set of patterns waiting for your discovery and participation, and they don't require you to obscure the intension of your code with compiler pragma noise like interface types, generics, and casting.

If you like to have your brain tickled by patterns, check out Design Patterns in Ruby (and consider paying close attention to the last section which offers patterns specific to Ruby and dynamic languages), or the Smalltalk Best Practice Patterns book by Kent Beck.

Stop waiting for the next immature .NET pseudo-port of a Ruby project. Just use the Ruby version. You don't need a .NET version of Gems just so that some social-climbing .NET open source celebrity-seeker can take a firmer grip on your attention. Just use Ruby Gems. Heck, you could use Ruby Gems right now for your .NET package management.

Stop waiting for ASP .NET MVC to catch up to Rails. Didn't you adopt open source to begin with because you were fed up with waiting for Microsoft's snail's pace of innovation and sunk-cost product management politics to catch up to the level of your expectations?

Despite Jeffrey Palermo's recent flattering of the ASP .NET MVC team's understanding of Test-Driven Development, Phil Haack and team were deeply in the weeds when it came to TDD, and to the credit of Phil's courage and integrity, he's left remnants of those difficult times in the clear for others to learn from. Making mistakes in public and having a consistent persona both on-camera and off are critical to establishing a community of integrity. The remnants of leadership in the ALT.NET community could learn a lot from Phil about this.

The repercussions of some naive MVC framework design decisions in ASP .NET MVC may never be rooted out of the framework because of Microsoft's bureaucratic policies regarding the need for near-infinite backward compatibility for those massive corporate Microsoft customers who cannot create the kinds of learning organizations that mitigate these kinds of problems. Rails, on the other hand, simply does not labor under the same drastic limitations.

Burn Me! I'm a Witch!

I know that I'm going to catch more heat for this article. People will say that I'm unrealistic to think that .NET shops can adopt Rails, although I, and many others, have led .NET shops through Rails adoption. They may point to the Rails project failure at Dovetail as an example without pointing out that the current project at Dovetail is more than 100% over-budget, and seems to produce more open source and celebrity than money. Mention of product and team management failures at Dovetail might also also be neglected. We shall see.

It may be said that I'm out of step with what ALT.NET has evolved into (something that I feel an immense source of personal and ethical accomplishment about) without pointing out that I'm still dedicated to living my professional life as an example of on-going community service, knowing that through the many years that I have been doing it have shown me that seemingly insurmountable changes can be made in relatively short periods of time with a community of practice focused on bigger goals than celebrity entitlement.

And most trivially, my lack of talent in structuring short, clear sentences may be used to malign the message that they contain in an effort to continue to sideline me and my perpetual pleading for more critical thinking driven by experiential learning and community service in the .NET community.

I haven't stopped asking the .NET community to stretch out beyond Microsoft's own sunk-cost imperatives - not since I founded the Austin .NET User Group in 2001; not since becoming chairman of the INETA speaker committee and working to get more progressive speakers involved who weren't purveyors of Microsoft's message; not since getting involved with DevTeach years before the vast majority of you had heard of it and working toward a day when the conference would feature progressive topics; not since organizing the ALT.NET Summit in an effort to insulate it and the practices that it advocates from the ravages of fleeting fad; not since writing and organizing the popular movement to redirect the Entity Framework team into more responsible and sustainable design (and subsequently quietly teaching them a Test-Driven Development workshop sans compensation); not since putting my MVP status on the line for my principles rather than allowing it or money gigs with Redmond to modulate my values; not since establishing the Progressive .NET events in London and Stockholm to encourage teaching in the .NET community rather than just speaking (although the celebrities that I'd gotten involved in that event have since refuted any responsibility to form a teaching practice and I've distanced myself from the events); not since organizing the Monospace events in Austin and Oslo to promote open source and diversity in the .NET space; not since working with the Austin Software Mentors group who are tutoring University of Texas students on contemporary software development techniques to prepare them for the real world after graduation; not since founding and facilitating the Lean Software Austin group to deepen the dialog in our community about meaningful productivity above and beyond celebrity agile; and not since connecting countless software developers to countless opportunities free of the mindlessness that accretes around entrenched entitlement power cliques in the Microsoft community.

And I'm reaching out to you again - asking you to reconsider your adoption of ASP .NET MVC over Rails and your fixation with editor-assisted programming and design over using IronRuby and Ruby.

There's an amazing world of capabilities that you've yet to discover far beyond static design pattern puzzles and ReSharper-Driven Development. There's a seed of courage that I'm counting on that I hope is still alive and well in .NET community even if it has been dormant for some time in the cold leadership vacuum left behind by the abandonment of .NET by some of our best and brightest.

In the end, you live your career life for yourself and not for me. And hopefully you won't be living it for the pleasure of folks who benefit from keeping you bogged down in a status quo that serves their interests more than yours. I may be asking you to take a more giant leap than you're ready for, but at least I'm not asking you to choose stasis. And I hope that the personal sacrifices that I've made for .NET community over the past ten years have left a modicum of credibility that would have you consider this:

IronRuby has dropped. Hear it? It will change your outlook on so much of what you do as a programmer and open you to a much broader world of software development and possibility. Trust me on this one. I've never given you a reason to doubt that I'm in your corner; that I've got your back; and that I'll drop what I'm doing to spend time with you learning and teaching rather than defending the fiefdom of my own .NET celebrity.

IronRuby isn't a magical vessel that holds mystical truths, but it just may be the next leap forward in your programming that Dave hinted at back in 2007 before all of this proceeded from movement to establishment.

Wednesday, February 17, 2010

Speaking at the Lean Software and Systems Consortium Conference in April

I'll be speaking at the Lean Software and Systems Consortium Conference, taking place in Atlanta from April 21st to 23rd.

My talk addresses the more egregious losses of productivity that come from working with HTML specialists in rapid startups, and how to shape the work, workflow, and team system to leverage the power of specialists without incurring the specialist tax.

Abstract:
Web designers are highly-specialized professionals. We lose a lot of productivity due to the effects of this specialization, whether through rework, scrap work, relearning, or missed expectations. Rapid startups expect to be up and running within two months, from the start of development work to business launch. Web designers are critical members of web startup teams, and learning to deal with web design specialists is vital to a rapid startup’s ability to sustain its pace. This presentation talks about two web startups that applied lean thinking and pull and flow to this particular challenge, and the techniques and understanding that came from the experience.

Check out the full agenda on the LeanSSC conference website:
http://atlanta2010.leanssc.org/agenda



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