PhatBoyG.com

This past week I had the pleasure of attending the Heartland Developers Conference in Omaha, Nebraska. I was already in town visiting family and decided to take a day to see what the local flavor had to offer. I’m particularly grateful to Joe Olsen of PhenomBlue for allowing me to register. I was originally hoping to secure a spot as a presenter, but the list apparently fills up in early March so next year I’ll try to plan for it.

On Wednesday night, a pre-party for attendees was held at the Qwest center. I rolled into the event around 9:00 PM (after watching the first part of the debate) and introduced myself to a few of the people there. Some of the folks I met included Jason Bock, Chris Williams, Joe Olsen, Amanda Laucher, Jeff Julian, and John Alexander. It was nice since there were some drink tickets being passed around and Rock Band 2 was going in the corner. I talked with several of the folks there and left looking forward to the content that was on tap for the coming day.

The morning of the event there was a lot of time to mill about before the sessions got underway (particularly since I got a ride from my mom and was there at 6:45 AM). Early on I found Joe Stagner (blog) and chatted about his recent hard drive upgrade amongst other things. I later met Clint Edmonson, an architect evangelist with Microsoft and discussed the content of the session he was delivering that day. There were a lot of good sessions at overlapping times so I wasn’t able to attend them all unfortunately. Once I settled down for the keynote next to Jason Bock, I caught up on some email and listened to Joe’s presentation.

My first session of the day was Jason Bock (blog, twitter) who spoke on Reflection and IL, including using Cecil for some post-build IL weaving. Very interesting topic for me and a great presentation. I spoke to Jason the night before to see if he had looked at any of the new expression tree tools in 3.5 and how to use them to build code on-the-fly without using Emit. It was an interesting discussion, Jason is a smart guy.

When it was time for lunch, a few of us went over to Farrell’s Bar and had some nachos and a burger. I found it funny since I was the only one from the south, I was also the only one who enjoyed the jalepenos. We chatted in general about community involvement and various events where we all had attended/presented and overall was a great discussion.

After lunch, Drew Robbins (blog) presented on the Microsoft Extensibility Framework (MEF, web). Despite a stuffy head that made MEF sound like “METH” I got a lot of great information and look forward to learning more about this new framework. The way you specify exports and imports really makes it easy to define an extensible application. I’m certainly going to look at ways to use MEF with MassTransit in order to provide a new way to compose services that consume messages.

I had to take a rest for a while, chatting with the Geeks With Blogs guys for a while and generally just taking it easy. After bouncing around I settled into Chris Williams’ (blog, wrap-up) talk on XNA. I’ve never looked at the game development tools for Windows, but I got a brief into as to what to expect. Once this session was up, it was break time. I was planning on doing a podcast with the Geeks With Blogs guys but was trumped when Joe Stagner and Amanda Laucher sat down to do a joint session.

The day was great and I learned a few things. I also got to meet some great people and had some interesting conversation. I had hoped to attend the F# presentation by Amanda Laucher (blog) and the Open Source presentation by Javier Lozano (blog), but I wasn’t able to return for day two of the event. The time on the day I went was well spent and I look forward to attending HDC again in 2009.

In two weeks, the 2008 installment of Tulsa TechFest will be upon us. For two days, Tulsa is going to unleash an impressive array of sessions on all aspects of IT, security, and software development. As I review the broad list of presenters I can’t help but see conflicting sessions where I’m going to have to make some tough choices.

If you are going to be anywhere near the Tulsa area and can manage to slip away from work for a couple of days I highly recommend making an appearance. The breadth of learning opportunities at the unbelievable price ($2/day) make this an incredible way to learn some new skills and sharpen your existing ones.

I will be presenting in two sessions this year. The first session will be on building distributed application using MassTransit (co-hosted by Dru Sellers) and other open-source frameworks for .NET. This is doing to be a deep view on how to build loosely-coupled systems on top of a messaging service (in this case, MSMQ). Advanced topics include asynchronous messaging and sagas (long-lived transactions).

The second session will be an introduction to iPhone development. I’m not a seasoned expert here, but I’m impressed with the platform provided by Apple (Xcode) free of charge for building applications for Mac OS X and the iPhone. This introduction will cover the tools and application structure for building iPhone applications in Objective-C.

If you happen to see me there, feel free to stop me and say hello.

I came up with this a month or two ago, but finally decided to share it. While working on Mass Transit, I was joking with Dru Sellers about how nice it was to have really good test coverage when making design changes to some all-new development code. I’ve had very limited opportunity for a completely new projected started purely from unit tests, so I was just impressed at how easy it was to make code changes knowing that a passing set of tests meant all was well in the world.

You see, not all parking lots are paved with quality asphalt, generally flat, and void of any obstructions like islands and lights (see my other hobby). At work, our application is a lot of vintage C++ code, a ton of stored procedures packed to the hilt with domain logic, and nearly zero percent unit test coverage. Since adapting agile development, it is something that has been missing from our process. In our latest iteration, we’ve started using unit tests (with NUnit) to design our interfaces and classes. At the same time, we’re integrating Mass Transit to support the loosely coupled layer of application services (which include object translation, communication with high-latency remote systems, and lazy auditing of transactions). Aside from a few basic web services to support remote client application support tools, this is the first C#/.NET development that is being done as part of the main application.

So back to our story, my first project with really good test coverage exposed me to a lot of new things. From a TDD perspective, I’d read about it, used it to build some basic tests for various classes, and thought I had a pretty decent understanding of it. In this new project, I also learned how to use Rhino.Mocks (which took the test run time from 40-50 seconds down to 1.83 seconds on average), a very powerful tool for making an interface behave as you would expect an implementation of that interface to behave. The use of mocks has really helped me focus on actually writing tests and building a single class at a time. Prior to using mocks I would jump around creating additional classes as I defined new interfaces just to be able to continue writing my unit tests on the original class. By using a mock, I’m able to simulate the behavior of the other class without losing focus.

As my appreciation for TDD grew, I jokingly dropped a slogan into a chat window (using Skype, of course, aren’t you?):

I got a few chuckles, and thought it would make a great t-shirt to wear to tech events like code camps. So I threw together a quick online store so that I could order one for myself. I showed it to a few others (like Joe Ocampo, who suggested the slightly less offensive, yet subtly more suggestive variant) and decided to make it available to anyone that wanted one. So if you like it, grab one for yourself and maybe I’ll see you wearing it at ALT.NET Seattle!

Over the past two weeks, my department has been working on our first iteration using agile practices. Yesterday, we wrapped up with a retrospective to go over our progress. We used a fish bowl to keep the conversation centered and focused — a method that once again proved to be useful for controlling a discussion without controlling the discussion.

We setup a whiteboard with columns for the following topics:

Start
Things that we should start doing on the next iteration.

Continue
Things that we should continue to do every iteration.

Stop
Things that we should stop doing.

Debt
Things that we did (or didn’t) do that will contribute to our technical debt.

We started with an introduction to the retrospective, a declaration of our goals, and a quick recap of how the fish bowl works. We also identified a remote advocate — a single person who is responsible for coordinating communication with our remote team members. Our company uses Live Meeting for conferencing, so we explained how to use the seating chart and how to use the Raise Hand feature. The advocate also had their IM client up for any out-of-band questions or issues with the meeting client. Once that was up and running, we opened the discussion.

Some of the topics discussed:

• Start making sure the acceptance criteria are well defined before starting the story.
• Start pairing throughout the development of the engineering tasks and not just at the end for review
• Start keeping an audit trail of initials of people who worked on a story or an engineering task
• Stop putting incomplete stories into the backlog
• Continue the daily stand up meeting format

There were many more, but you can see how the structure worked. In all, we identified around 20 items that we need to either start, stop, or continue.

Once that segment of the meeting was over, we went over some of the methods being used to track things like burn down. Our project manager (whom we have yet to designate with a more appropriate agile title) went over the spreadsheet she uses to track story points, engineering task estimates, and actual hours worked on each task. She then showed some web sites from other groups in the company doing Scrum and how they had organized their Wiki, how they posted pictures of their planning board and burn down chart, and their honorary stuffed ScrumMaster.

We did have a few bumps towards the end of the iteration with our test environment and the number of defects coming back from testing (which is why we want to start pairing earlier). We hope to improve with each iteration (of course) but for our first lap around the track I think we did pretty well!

On Monday, we started our first iteration. We spent the previous two weeks discussing the process, preparing stories, and learning how we can adapt extreme programming (XP) practices into our development process.

We kicked off with iteration planning to identify the engineering tasks associated with the stories in the iteration backlog. We gave estimated in ideal hours for each of the tasks and added them to the story cards. Once the planning was done, people picked up tasks they were going to work on (some were assigned, others volunteered) that day. We made a point to assign a peer to work with the task owner until the task is finished.

Every morning at 9 AM, we have a stand up meeting with the team to go over each member’s progress from the previous day, plans for that day, and any roadblocks that are inhibiting forward momentum. Once each person was done, we got down to business and started work on our tasks. Full-time pairing has been limited so far, only a few have been pairing for the engineering tasks. I’m sure it will take time to adjust to what works best for the members of the team.

For project tracking, we are using a physical planning board with the cards pinned to the board. We tried a number of electronic methods to improve collaboration with our remote team members, but the tools just got in the way of the process. We are going to follow up in our retrospective with the remote teammates to determine how we can improve their involvement in the daily workflow. For now, they are communicating via e-mail and phone with our project manager who is working with me for our daily focus (like a scrum master, but in XP terms that I can’t remember).

One of the initial things we found is that it is really important to mark on the cards WHO is working on the engineering tasks associated with the story. Without this step, members of the team sometimes lost track of what they were doing and ended up working on other things. The ownership of the story once picked up really needs to be communicated well with the team to make sure multiple people don’t end up doing the same work.

I paired with another team member on a forward deployed application that is part of our system. I’m fairly experienced with the program whereas my pair-mate (?) had no experience with it. We managed to complete a couple of stories in the first three days of the iteration, some solid progress in my opinion. We spent a lot of time testing various scenarios to ensure the changes we made didn’t break anything. Once each story was complete, we did the paperwork to integrate our code changes into SVN. Yes, we have paperwork for each change to ensure compliance with SOx.

We had a couple of stories that we found did not have a sufficient level of detail in the acceptance criteria to complete. After working with the stakeholder on the story and acceptance criteria, the estimate changed and we’re trying to determine if there is room enough in this iteration to complete it properly.

Our application has been live for several years, so we have members of the team that handle support for our production systems. Starting this week, defects that are found in production are red-carded and put into the Inbox on the planning wall (we are using red cards for defects). We then take a few minutes to estimate the defect and depending on the size either add it to the iteration or put it into the release backlog for the next iteration. This allows us to quickly get production issues fixed and delivered for system testing by our SQA department.

This week we’ve also been working with product management on stories for large upcoming features that are being added to the product. That has been a very good experience, particularly in how we are building our knowledge of the user behavior that is being requested. I’m even thinking of how we could write a series of how-to documents on using the new system features based on the stories we are writing — I’m sure our documentation team with love that!

So I’m encouraged by our progress so far, but overwhelmed with the pace at which we’ve adapted these new practices. It seems like only a couple of weeks ago I was having meetings with our management team about moving to a more agile development process and here we are today almost midway through our first iteration. Let’s hope we can sustain our pace, keep the backlog full, and finish our first iteration with success.

Last week, I started looking into using WATIR for web application testing. In the short amount of time I spent with the tool, I got an initial look at Ruby. Aside from seeing it here or there, this was the first time I actually wrote any Ruby code — but it was mostly cut and paste based on the testing examples.

Today, I realized that Ruby (and Ruby on Rails) is part of Leopard and delivered with OSX. So I fired up a terminal window and started playing around with the console (IRB). Mind you, I was only playing around with it at this point so I didn’t get too deep. I created a few classes, learned the value of open classes, added some methods to the built-in classes (like String.is_your_mom), etc. I was basically playing around without any instructions.

Tonight, I started reading a few articles on the Apple web site about getting started with Ruby on Rails using Mac OSX. I created an application, created some models and a migration, installed and configured MySQL for use in development and test, and created some scaffolding to be able to perform basic CRUD against my domain model. It was at this point that I got an idea of how web applications could be created using Ruby on Rails.

The part that concerns me with what I’ve learned so far is that ActiveRecord is handling all of the mapping of database columns do the domain model. I’m not sure this is how I would really want that to be done, but I’m so new to Ruby I can’t be sure. I’m going to find some examples of applying DDD to Ruby on Rails and see if the two play nicely together. It seems like a lot of the Ruby framework expects a lot of things to be named specific ways or it all breaks down quickly. I do know that I’m not a big fan of having the model defined from the database.

I also know that building an application with a Rails web interface might also lead to building supporting application services in other languages using the same database. In that case, it would seem that having a model-driven architecture that can generate the classes for both Ruby and C# (and likely Java) would be very useful. I have Sparx EA, but I’m not sure if it supports Ruby yet or even if that is how I would want to go.

I’m going to pick up a couple of Ruby books to read more about it — it seems Idiomatic Ruby is a good place to start. Who knows where that will lead!

Since we had our agile fishbowl at work, we’ve moved ahead with adapting agile practices in our development process. For our projects, we’re working on creating user stories to fill our product backlog. I’ve read several threads on writing good user stories and gotten advice from several people on what makes a good user story, but I never realized how hard it is to actually write good user stories.For user stories, we’re using a format that includes:

• The role for the story, is it a user, a specific type of user, or a customer
• The context of the story, describing what the user is doing
• The want of the story, describing how the feature should behave

The clarity of user stories over requirements is both amazing and overwhelming. The amazing part is understanding the intent of the story in the context of the user and how it affects their usage of the system as a whole. The overwhelming part is negotiating with the stakeholder to ensure both the context and the behavior have been properly captured and an adequate number of acceptance criteria have been defined. While this certainly increases the amount of time spent on a particular story, the number of details revealed by the discussion is well worth the effort.Finding Good ExamplesOne of the stumbling blocks I found when learning to write user stories is finding good examples that go beyond the typical “As an account holder, I want to withdraw money from my checking account so I can buy crack.” These textbook examples don’t really provide a significant level of depth, something I deal with when identifying improvements to an existing system. For example, here is a story that could be written:

As a customer, I want to verify the correct billing codes were included on the claim before sending it to the payer to avoid rejections.

This enhancement to an existing claim submission system might include a number of checkpoints where such a verification could be performed. The context really helps clarify this story to ensure it is properly implemented:

When importing claims, the billing codes in the 2100 loop of the 837 file should be compared to a list of known, valid billing codes and claims with invalid codes should held.

This additional context indicates that the billing codes should be checked when importing claims, a process that likely occurs on a daily basis. It is assumed that the user would then take the list of claims containing invalid codes and correct them in the originating system. This assumption, however, is just that as the story doesn’t attempt to describe any behavior of how held claims should be handled.

When a user is modifying a held claim, changes to the billing code elements should cause those elements to be reverified. If the billing codes are changed to valid codes, the claim hold should be removed.

This one gets a bit tricky. While dealing with the verification of billing codes on a claim, what is really being described is a new behavior. In my eyes, this means it is a different story.

As a user, I want to be able to correct the billing codes on a held claim so that I don’t have to re-import the claim for it to be sent to the payer.

Here we are describing the new behavior — the ability to modify the billing codes on the held claim. For this story, the previous context would be more applicable since it is dealing with the user activity of modifying the billing codes on a claim.Stories That Aren’t User StoriesSo what about things that are needed to support the above stories? No, really, that’s a question since I don’t have a really good answer at this point. Do you write a story to import a list of valid billing codes? Or do you write a user story to automatically download and import a list of valid billing codes from the payer every night? Where do those system-level stories go and how are they written? There really isn’t a role associated with the story, so I’m still struggling with that type of story.One such example might be something like:

As an application administrator, I want to be able to import a list of valid billing codes so that I can update the verification tables.

The context of such a story might include:

When an application administrator uploads a file containing billing codes, the existing billing code table should be cleared and the new codes added.

OnwardI didn’t really get into acceptance criteria in this post because that in itself is a series of posts. I will mention that having a deep set of acceptance criteria on a story will make it easier to estimate (size) the story, as well as improve your chance at success in implementing the story.If you as the reader have some good examples of stories that aren’t associated with a particular role, please share them in the comments as I’m really looking for some better examples of how these stories would be written.

Last week I decided that I’ve read enough, been exposed to enough, and gotten as far as I can get with agile software development without actually doing it. So I went in to our senior management and shared my experiences from the past few development events with them and managed to convince them to try and adapt some agile practices into our development process. By bringing forth the pain points we have during development (unknown status, slipping deadlines, inaccurate estimates, excessive impact from changes, etc.), I started to explain how we could gain greater transparency to our development process using certain agile practices.

After a few preparation meetings and a lot more discussion I introduced story writing and planning poker to the group today. I haven’t gotten enough feedback yet, but we are going to continue fleshing out our first batch of stories to fill our product backlog. Once we’ve collected some stories, we’re going to estimate them to get some experience with the process. If all goes well, I expect we’ll start our first iteration next week.

I’m encouraged so far, but there is still a lot of work to be done.