Jeremy’s other contributions to the community include StructureMap and an obtuse fascination with separation patterns for user interfaces.

Story Teller is an alternative for Fitnesse, implemented in .NET and chases the holy grail of executable requirements. If you are interested in how to achieve the promise of shared and executable requirements, this just might be your tool.

• Story Teller
• Jeremy’s StoryTeller post on a preview release

Get the show here

Things That Went Well

• I was impressed by everyone's enthusiasm. I was a little worried that we were under-prepared going in, but the enthusiasm and depth of knowledge that the presenters shared was impressive.
• People really liked the Outside-in Testing (Jeff Olson) and TDD sessions (Robin Clowers). These had the most code shown during their presentations, which, I think, says something.
• The facilities were just about right. We were a tiny bit over capacity (technically we were under, but it didn't feel that way to me.)
• We had the right refreshments and stuff to keep people from getting hungry and distracted. At one point, someone I know asked if we had anything besides pizza, as he has dietary reasons for avoiding it. I felt bad and told him no, making a mental note that we should have some other food available next time, until I realized Anne had prepared Salad and lunch meats. Yay!

To Work on for Next Time

• We tried to cover way to much ground for one day. I think we all knew this going in, but were just in denial or something. Next time: I think we're going to cover just one topic.
• We hardly got to show any code. I had code that I wanted to show for both the refactoring and patterns talks that I didn't even get to. I got to show a tiny bit of code in the refactoring talk, but I had a whole series of small refactorings I wanted to do but didn't. I think we went over in a few of the earlier sessions, it felt right then, but then it compressed the sessions for the rest of the day. The one person that just showed code the whole time, Robin, received props for that. Next time: no slides for me.
• We asked people to bring laptops, then never worked on any code. This was mostly a side effect of the above, I think. Next time: give them the code ahead of time and use the pauses while people catch up with coding tasks to answer off-the-rails questions.
• Some people weren't into the whole "be interactive" thing. At the start of the workshop we asked everyone to shout out questions as soon as they had them, but some felt this led to derailment. Next time: I think we'll save space at the end or at pre-determined spots for questions, although I personally feel this leads to people forgetting their questions.
• We (the hosts) didn't communicate enough before the event and I think it showed. Next time: I think we need to get together on a Saturday a few weeks before the event and make sure we're all on the same page. I think this is one area where I personally did a pretty poor job, kind of assuming everyone was "directionally correct" and just kind of knew what to do. For the most part this was true, but I think this will be something we improve upon.
• Using git and markdown was great for the geekier amongst us, but proved a burden for some of the presenters and the attendees. Next time: git for us to share the code, zip files (skydrive?) for everything else and for code for the attendees to download.

In summary, I think the loudest message was: more code. I am in total agreement and I usually don't like to use any slides at all if I can help it, but somehow got the wrong headed idea that I needed to have something to look at while I did the talking, intro-part of my sessions.

I also tried rehearsing more than usual for this and it turned out to be a complete waste of time. The actual session went wayyyy slower than then I rehearsed. I must be doing it wrong. // TODO: Imagine Arun
asking questions while I am rehearsing.

It sounded like the majority of the attendees would like to come back for another session like this, more focused on one topic. The organizers are going to hold a skype retrospective sometime in the next few days and figure out what we want to do next.

I’d like to give mass props to the people that made this happen: Justin Bozonier, Robin Clowers, Bobby Johnson, Jeff Olson, Trevor Rotzien, and Anne Wax. Together we are helping ALT.NET grow from a small fringe group into something that’s doing real work and making things better than when we got here.

UPDATE: We actually held the retrospective last night. We're planning another event soon, possibly in more locations, something more focused. Keep your eyes peeled.

You're at work and you catch yourself writing another 100 line method that you can't test and really can't even understand. You scour the internet for ideas but there are so many ideas. Some say don't test, others says don't test anything, still others say test every keystroke! You just let your head drop to your desk with a solid thud. You think to yourself, "Is this really the best I can do?" The Olympia Software Craftsmanship Workshop is one day workshop, developed with the intention of increasing the level of awareness of practices and skills that can improve our software. Any developer interested in improving and learning new skills is welcome. If you can bring a laptop, please do. We will provide the software you need. If you can't bring a laptop, don't worry, you can pair up with someone who has one. ************************************************************************* What: Olympia Software Craftsmanship Workshop Where: Olympia Center, 222 Columbia St NW, Olympia, WA 98501 When: Saturday June 6, 2009.  10 am to 4 pm How much does it cost? .00 to cover the cost of the facility and lunch. How do I sign up? Go to www.olympiasoftwarecraftsmanship.org The workshop is hosted by members of the South Sound.NET users group and Alt.Net Seattle who want to help others build better software. For more information: http://github.com/altnetseattle/olympia_software_craftsmanship_workshop/tree/master Or contact Bobby Johnson at bobby.johnson@gmail.com

Upcoming Topics:

Before You Begin

Project Setup

• FubuSample
  • lib
  • src
    • FubuSample.Core
    • FubuSample.Web
    • FubuSample.Tests
    • FubuSample.sln

1. 1. FubuSample.Core
      1. FubuMVC.Core
      2. FubuMVC.Container.StructureMap
      3. StructureMap
      4. Microsoft.Practices.ServiceLocation
   2. FubuSample.Web
      1. FubuSample.Core
      2. FubuMVC.Core
      3. FubuMVC.Container.StructureMap
      4. StructureMap
      5. Microsoft.Practices.ServiceLocation
   3. FubuSample.Tests
      1. FubuSample.Core
      2. FubuSample.Web
      3. FubuMVC.Core
      4. FubuMVC.Container.StructureMap
      5. NUnit.Framework
      6. Rhino.Mocks
      7. StructureMap

Taken from the website:

The Continuous Improvement in Software Development Conference challenges participants to consider contemporary technical and cultural practices in the software development community in terms of continuous improvement.

During breakout sessions, demonstrations, and conversations addressing practices, tools, process, methodology, and community and culture, participants are asked to consider and respond to the following questions:

• How do we improve?
• How do we recognize new improvements?
• What improvements in the past led us to where we are now?
• How do we decide which improvements to make?
• What values drive our decisions for improvement?
• What improvements can we be making right now?
• What obstructions impede improvement?
• What improvements are on the horizon?
• How can we adapt easier to the changes that improvements bring?
• What are the practices and processes that enable improvement?

Things That Went Well

• I was impressed by everyone's enthusiasm. I was a little worried that we were under-prepared going in, but the enthusiasm and depth of knowledge that the presenters shared was impressive.
• People really liked the Outside-in Testing (Jeff Olson) and TDD sessions (Robin Clowers). These had the most code shown during their presentations, which, I think, says something.
• The facilities were just about right. We were a tiny bit over capacity (technically we were under, but it didn't feel that way to me.)
• We had the right refreshments and stuff to keep people from getting hungry and distracted. At one point, someone I know asked if we had anything besides pizza, as he has dietary reasons for avoiding it. I felt bad and told him no, making a mental note that we should have some other food available next time, until I realized Anne had prepared Salad and lunch meats. Yay!

To Work on for Next Time

• We tried to cover way to much ground for one day. I think we all knew this going in, but were just in denial or something. Next time: I think we're going to cover just one topic.
• We hardly got to show any code. I had code that I wanted to show for both the refactoring and patterns talks that I didn't even get to. I got to show a tiny bit of code in the refactoring talk, but I had a whole series of small refactorings I wanted to do but didn't. I think we went over in a few of the earlier sessions, it felt right then, but then it compressed the sessions for the rest of the day. The one person that just showed code the whole time, Robin, received props for that. Next time: no slides for me.
• We asked people to bring laptops, then never worked on any code. This was mostly a side effect of the above, I think. Next time: give them the code ahead of time and use the pauses while people catch up with coding tasks to answer off-the-rails questions.
• Some people weren't into the whole "be interactive" thing. At the start of the workshop we asked everyone to shout out questions as soon as they had them, but some felt this led to derailment. Next time: I think we'll save space at the end or at pre-determined spots for questions, although I personally feel this leads to people forgetting their questions.
• We (the hosts) didn't communicate enough before the event and I think it showed. Next time: I think we need to get together on a Saturday a few weeks before the event and make sure we're all on the same page. I think this is one area where I personally did a pretty poor job, kind of assuming everyone was "directionally correct" and just kind of knew what to do. For the most part this was true, but I think this will be something we improve upon.
• Using git and markdown was great for the geekier amongst us, but proved a burden for some of the presenters and the attendees. Next time: git for us to share the code, zip files (skydrive?) for everything else and for code for the attendees to download.

In summary, I think the loudest message was: more code. I am in total agreement and I usually don't like to use any slides at all if I can help it, but somehow got the wrong headed idea that I needed to have something to look at while I did the talking, intro-part of my sessions.

I also tried rehearsing more than usual for this and it turned out to be a complete waste of time. The actual session went wayyyy slower than then I rehearsed. I must be doing it wrong. // TODO: Imagine Arun
asking questions while I am rehearsing.

It sounded like the majority of the attendees would like to come back for another session like this, more focused on one topic. The organizers are going to hold a skype retrospective sometime in the next few days and figure out what we want to do next.

I’d like to give mass props to the people that made this happen: Justin Bozonier, Robin Clowers, Bobby Johnson, Jeff Olson, Trevor Rotzien, and Anne Wax. Together we are helping ALT.NET grow from a small fringe group into something that’s doing real work and making things better than when we got here.

UPDATE: We actually held the retrospective last night. We're planning another event soon, possibly in more locations, something more focused. Keep your eyes peeled.