In a couple weeks, myself and about a hundred some odd other folks are converging on Austin for the ALT.NET Open Spaces event. Just to get myself ready, here are the things I’m thinking about before we all get there.
The most important part of ALT.NET for me is simply being on the quest for better ways of building software. For too long we’ve allowed our tool vendor to do far too much of our thinking for us. We need to sit up and make our own value judgements about how we build software. We should have the tools shaped to fit our values, not our values shaped around the tools.
What’s Next? Where are we going? What are you interested in?
We’re using the Open Spaces event format, meaning that the conference agenda is decided upon by the attendees when we get there. There’s a list of possible topics on the conference’s homepage. You’ll have to fill in your own topics, but I’ll give you mine. The topics that I want to talk about are:
- Language Oriented Programming. Textual Domain Specific Languages. Writing code in higher levels of abstraction to increase the signal to noise ratio. Writing more expressive and elegant code that’s easier to understand. Packing more punch with each line of code. Fluent interfaces in C#, DSL’s in Boo, and the far out stuff happening in the Ruby space. Getting things done in code in one place as opposed to scattering little breadcrumbs of meaning in Xml or Xaml files, attributes, and various modeling schemes.
- Executable Requirements. I think this is one of the biggest unattained goals/dreams of Agile development. Toolwise, either Fit (StoryTeller!) needs to improve or we get lined up behind the xBehave tools. Process wise, we’ve got to figure out how to get the customers, analysts, testers, and developers on the same page to get this done. I’m looking forward to meeting the Lostechies guys and see what they’re up to in this regard.
- I wanna see if Scott Bellware can make a coherent case for BDD as something totally new, different, and better than simply doing TDD and acceptance testing well
- There is representation from both MbUnit and the new xUnit.Net tool there. I’ve pretty well assumed that innovation in the xUnit space was basically dead with xSpec tooling coming on strong, but let’s see if I need to sit up and pay more attention.
- And yes, I’m anxious to hear more experience reports from folks that are doing development work with Ruby on Rails or MonoRail.
- There’s a rumor that we’re going to see something tangible from ScottGu’s garage project to build a true Rails-like MVC framework.
LINQ isn’t important
LINQ is sexy. LINQ is cool. LINQ isn’t particularly important in the greater scheme of things.
I could just have easily said WCF or WPF or WF in place of LINQ. All of those things are improvements in tooling, but not a revelation. We (the .Net development community) put far too much emphasis on knowing libraries, API’s, and technology tricks. In the end, what’s more important to being successful? Knowing obscure facts about ADO.Net or understanding how to create a solid separation of concerns between your business logic and your database?
What I think is lacking in .Net is a greater appreciation for core development skills like OOP and software engineering practices. RAD tooling might enable us to write code quickly, but we know it doesn’t lead to sustainable development efforts. The first order factor in the productivity and quality equations is the capability of the folks designing, writing, and testing the code. If there’s anything I’d like to be a part of “ALT.NET” it’s the importance of building a solid core[LINK to JP].
The Elephant in the Room
The very real and obvious problem for us in ALT.NET is the general lack of skill, knowledge, and experience with the techniques, practices, and patterns that we’re espousing in the .Net community at large. I’ve been interviewing people for .Net positions for my company and our parent company over the last couple months. Here’s the typical skillset I keep seeing: calling stored procedures that someone else wrote, grabbing the DataSet coming back, and slapping the DataSet’s into databound controls. That’s it. They know how to use the most common tools in Visual Studio and .Net but don’t have any real deep knowledge of OOP, software design concepts, and the Agile practices that I think are valuable. They simply don’t have the background and skillset to work the way that I feel is best.
For example, I think Model View Presenter (MVP) designs are the best way to create a maintainable WinForms application. The harsh reality is that MVP really works best with a team of developers that understand the MVP pattern in specific and Object Oriented Programming in general, at least enough to understand the separation of concerns that we’re trying to achieve and why we want to achieve that separation. Unlocking the goodness of MVP requires a deep knowledge and understanding of coding and design. The .Net developer community at large simply does not have the deep seated coding skill and experience with patterns that makes a code centric approach like MVP succeed. MVP flies in the face of out of the box WinForms, and that makes it very difficult to find developers who can work in that way. Going farther, using MVP with TDD, CI, and all the good stuff, may actually do more harm if the developers building the system and following me when I go on to my next consulting project don’t have any clue about MVP.
The neverending questions are:
- Can we improve the situation? Can we democratize the skills and patterns we already think are best?
- How do we improve the situation? At least enough to be able to find other developers to make our development style sustainable and feasible?
- Do we just give up and jump to Ruby or Python instead where they seem to get it? I don’t think I’m capable of forcing my development style into the MSDN mold, so this eventual move has to figure into my future planning. In a way, I’d rather be somewhere where I don’t stick out like a sore thumb. More on this below.
Your developers can
Far too often I hear the refrain “our developers just can’t do that.” There’s a clear assumption that visual programming and Rapid Application Development tooling is the only way that the average developer can produce code. We’ve got to break this self-defeating attitude. Much of the reason that the average .Net developer can only work with RAD tooling and data centric development is simply because that’s the only thing that they’re exposed to at work. Learning the RAD tooling is often nontrivial, and there’s not much in all of mainstream development as complicated as the WebForms event pipeline. So why can’t the average .Net developer learn to do things in another way? Given a chance and some guidance, I don’t see why an average developer couldn’t embrace the practices and patterns of development most associated with ALT.NET.
Is .Net Middle Earth, Ruby the lands across the sea, and MonoRail the Gray Havens?
More than one person has questioned whether or not the ALT.NET canon and crowd is inevitably destined for Ruby and Ruby on Rails. There’s some thought, and at this point observation, that the alpha geeks in .Net are starting to drift into Ruby development instead. If you’re willing to question the “MSDN way,” you’re much more likely to be exposed to RoR and open to giving it a try.
I think Ruby and Ruby on Rails has already drained quite a bit of the thought leadership out of Java, and you’ll definitely see some of that happening to .Net. Yeah, it has some issues with scalability and I’d question the ActiveRecord approach for complex domain models and databases, but those issues can be or will be beaten (RBatis & Rubinius maybe). The attraction of RoR and Ruby in general is how it completely embraces the Agile practices I want to use, and the coding and design values that I believe in. On the other hand, the .Net framework and Visual Studio tooling out of the box does not reflect the way I want to work.
This mismatch of values and framework presents me with a dilemma. Leave the nice, comfortable (staid) Microsoft development womb, or move on to this whole new Ruby world. There’s another alternative, and this is where I hope ALT.NET steps in. Can we change enough of the .Net community and tooling to make .Net development be what we want it to be? IronRuby is coming. ScottGu and co are working on some sort of MVC web development framework and MonoRail is already in production. C# 3 is coming with some more powerful language constructs (borrowed from other languages because there’s nothing new under the sun). F# is flying under the radar, but the F# team seems to be well on its way to productionalizing F# development (I’d really love to talk to someone doing real work with F#). The community awareness and adoption of Agile practices are on an upswing.
Is it too little too late though? Is Ruby inevitable for us? Would some folks be happy to see us leave .Net anyway? Is Microsoft serious enough about IronRuby to make it be more than a new form of VBScript to wire up Silverlight? Can we make the .Net community into something better? I’m sure all of these topics will get bounced around. I’ll try to provide the play by play here the following week.
Lastly, award yourself some serious geek points if you fully understood the title of this section.
What about the “ALT.NET” name?
There’s been some consternation over the name lately. I’ve decided that I just don’t care. Call it tangerine development if you want. The little “ALT.NET” moniker should disappear into the sands of history within a short amount of time anyway.
For those of you who didn’t get to come to Austin
The spots filled up fast, and there were quite a few folks who didn’t get a spot. All I can say is that one of two things is going to happen:
- It flops, in which case you didn’t blow your weekend
- It works, in which case it’ll only be the first of many ALT.NET events. I won’t speculate on when and where the next one will be, or in what format, but I can promise that there will be a next.
There’s an absurd amount of talented and thoughtful folks there, so I’m going to step back and let everyone else lead the sessions. What I will do is blog as much as possible about the proceedings as possible and write a long retrospective afterwards. I’m going to try to interact with as many people as possible and try to sample as many conversations as possible.
Other Folks on ALT.NET
- Jeffrey Palermo says we should enjoy our software development efforts. Scroll down to find Frans Bouma’s comment at the bottom too. There’s always better stuff coming up and our dearly held ideas about software construction have a nasty tendency to get overturned as our field progresses.
- David Laribee, the Kent Beck of ALT.NET, says there isn’t all that much new to ALT.NET. I’d say there’s two parts to this one. The first part is simply encouraging the usage of the things we already consider to be better practices, even when that’s in opposition to the .Net way inherently embedded in Microsoft tooling. The second part is an exhortation to keep looking for better and better ways of building software and to look in more than one place for those better ways.
- My old lunchtime basketball nemesis Joshua Flanagan weighs in with ALT.NET is freedom.
Jeremy’s Agenda at ALT.NET
Conference wise, I’m going to try to observe as much as possible, interact with as many people as possible, and write as many blog posts as possible. Otherwise, my agenda is to soak up as much Austin as I can before going back. I plan on hitting a lineup of my favorite Tex-Mex places and picking up a ”Keep Austin Weird” T-Shirt at Chuy’s for my son. After the conference on Saturday night I’m going to see Billie Joe Shaver play just outside of town at the Nutty Brown Cafe. Anybody who wants to see the quintessential Texas singer/songwriter (Willie Nelson and Waylon Jennings more or less did a Shaver tribute cd is that tells you anything) in action from a 100 feet away is welcome to come.
