Category Archives: Software Development

Items related to software development

Iteration One is a Wrap

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!

First Iteration, Week 1

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.

Ruby (on Rails)

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!

User Story Writing

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.

Adventures in Agile Development

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.

Safari 3 Debug Tools Better Than FireBug?

In my usual morning loop, I found the following tweaks to enable to Debug menu in Safari. In Leopard, Safari 3 debugging tools have gotten some serious love — I mean serious love. Let’s take a look!

First, you have to enable the debug menu on Safari. In Terminal, enter the following:

% defaults write com.apple.Safari IncludeDebugMenu 1

Once that is done, open safari (if it was running, it may need a restart) and notice the new Debug menu appended to the end of the standard menu. From here, you can open the web inspector and the world just opens up. There is so much stuff in here it’s hard to cover it all, but the features are deep. One of my favorite views is the network view that shows a timeline of the page load to find slow spots:

It’s pretty deep, I like it. I’m going to spend some more time with it, but I figured I would share it with those Mac dudes that are always into cool stuff.

Dependency Injection with Castle Windsor

I’m writing a presentation on dependency injection with Castle Windsor to give at work this coming week. I’m going to present it at a lunch and learn for the software developers in our department. It should be interesting, I’m curious to see how it goes. If all goes well, it will be the first of a series that I’m going to put together.

Once I have the content and have run through it, I’ll post the samples and text here for everyone to enjoy. While it is introductory in terms of DI/IoC, it’s a fairly advanced topic compared to general programming topics. Should be fun!

Tulsa TechFest Live

Tulsa TechFest 2007 started this morning (well, last night if you’re a speaker) and there is a huge turnout for the event. There are so many people spread out amongst all the tracks — much more than last year.

I started off the morning with a game of Guitar Hero II in Chris Koenig’s booth. Nothing says happiness like pounding out a couple of tracks to start the day. A majority of the morning activities consisted of registration, sign-in, announcements and keynotes. The first session started at 10:30 AM, which is when I gave my talk on MonoRail.

I had a decent turnout for an obscure framework and was happy with the talk. There was some good discussion on the parts around the framework (Windsor, NHibernate, ActiveRecord), and a lot of good questions. I forgot to put together an example on ViewComponents, so I’ll likely write a blog post in a few days about how to build one.

Lunch was quick, I think the pizza to developer ratio was slightly underestimated, but we could all use on less slice of pizza now and then. This afternoon looks to be packed, so I’m on to the next event.