ALT.NET Open Spaces Closing Day Recap
Impromptu Sessions
One of the best sessions was an impromptu session with Jeremy Miller on the StoryTeller tool and his future plans for it. If you're not familiar with it, it is a tool used to manage and create automated testing over the FitNesse Dot Net libraries and helps in an acceptance test driven development environment. Anyhow, a number of us managed to corner him at one point during the day and sure enough he had his laptop available. From there, we were able to encourage him to work on it some more as well as learn about where to go from where it is right now. Jeremy covers more about it here. Sometimes these impromtu sessions are some of the more valuable interactions to be had at events such as these.
More Video To Be Had
It seems that almost everyone had a camera at the event. Greg Young and Dave Laribee managed to capture a bit of the sessions on video. That's a great thing because I honestly wish I could have cloned myself and gone to more sessions. Hopefully more of this will be forthcoming. Dave posted Greg Young's fishbowl conversation on Architecture Futures which you can see here.
Other videos that are on this list are from John Lam's IronRuby session, Udi Dahan with ScottGu and Chad Myers talking about Microsoft and Open Source Software and so on. You can find them at the end of Greg's video.
Software Design Has Failed, What Can We Do About It?
Scott Koon, aka LazyCoder, convened with JP Boodhoo a session on how software design has failed us. This turned into a fishbowl conversation as well since there was a lot to be said. The basic points revolved around the large amount of software failures. What causes them? Are they technological issues? People issues? Politics? Many people brought their opinions to bear, and it was interesting that the point that I brought is that at the end of the day, customer satisfaction is the metric that matters. Are we listening to them? In the Agile methodology world, customer satisfaction is the only metric. Yes, we can talk about TDD/BDD, DDD and so on, but are we actually putting software into the hands of the user that they actually want?
I'm not forgetting of course the ideals around mentoring and helping make the team stronger. Those issues are important as well. Do we do pair programming? Do we hold brown bag sessions? All of those suggestions are key to helping grow a stronger team. But, also it helps grow the team as a more cohesive unit that's not afraid to ask questions, pair up and avoid flailing.
F# and Concurrency
Roy Osherove convened a session on concurrency and functional programming as the last topic I was going to attend. When we start to deal with multi-core environments, threading issues come to bear more frequently. Are we utilizing the CPUs to the maximum or are we still just sitting on that one thread, and barely using the machine to its capacity? Those are many of the issues we face. In Software Engineering Radio Episode 14, Ted Neward talks to this very point quite frankly that multi-threaded programming is hard. There are no two ways about it. But, when we talk about functional programming, some of that is solved. Why? Immutability by default is one of the key strong points of FP. Instead, you have to go out of your way to make a value to be mutable. Is this something we'll see in C# 4.0? Spec# has something to say about it. And once again, another topic for discussion. I keep putting these things on my plate...
Anyhow, Harry Pierson and I helped run this session. Harry had some of his parsing code that he has posted on his blog to show off. I think that did the trick well to show some advanced things such as high order functions, pattern matching, anonymous functions and so on. Instead, if you wish to learn more, I'll probably cover it here in some detail, but you can check chapter 13 of Don Syme's "Expert F#" book to learn more in the mean time.
Action Items
Some action items came up from this event that I think are rather important. Because ALT.NET is a community looking to improve itself, there are naturally some things that help. Here are a few that I can think of:
- Keep the conversation going
Just because the conference ended doesn't mean the conversations that started there have to.
- Start a local group
After the session was done, the altdotnet mailing list came alive with people wanting to create that ALT.NET groups like I did in DC, Brian Donahue did in Philly and Jeremy Jarrell did in Pittsburgh.
- Support the community
Ray Houston laid out a challenge for those who use Open Source products to donate to them. This doesn't mean only money, but time as well. Many projects are in need of some assistance, and all it takes is for someone to ask.
- Challenge Assumptions and Bring Change
It was said best during the conference "If you can't change your job, change your job". Don't let these discussions that happened here just stay there. Bring them to your work place, bring change for the better. Question why things are done the way they are.
Wrapping it Up
I'm glad to have been a part of this event in Seattle. It couldn't have been with a better bunch of people who are willing to better themselves, challenge themselves and their assumptions and bring change to the developer community. There was a lot to learn this past weekend and each conversation brought up a new angle. Until next time...
