class DirtyInformation

I've been thinking a lot lately about code katas and I wanted to come up with one on my own. Now I need to get it out there to find out what others think, and force my self to actually do it.

Simulate a checkout line at a retail store in order to find the best solution for keeping customers happy but minimizing checkout lanes.

• Specs
• Customers get in the shortest line every 40 seconds
• Customers of this store always buy 10 items.
• Each item takes 5 seconds to scan and bag
• Each customer takes another 20 seconds to pay and then they checker can start on the next customer
• Customers become unhappy if they have to wait more than 30 seconds before starting to checkout
• Customers leave after 50 seconds of waiting to checking out

• Questions
• How many lanes do I need to keep 80% of my customers happy?
• How many lanes do I need to keep all customers happy?
• How many lanes do I need to make sure no customers leave?

I know that this isn't really scientific, but I thought it might be fun. I also know that each run may come up with different results, but if I run it a lot I think I can come up with a good average.

The other night I spend forty-five minutes on the phone with a friend talking about what agile is. He hadn't been exposed to the ideas behind agile. When I started talking I don't think I really hit on what agile IS. I talked about practices and the way my team works. He had many of those methods in his experiences but not all of them, and not really in what I would consider agile. After I got off the phone I noticed that I only talked about practices and not about principles. So I thought to myself, "What IS agile?"

This is a hard question for me to answer. Every time I start to think about it I go back to the practices that I use in order to achieve what I consider agile. That isn't right. Agile isn't a set of practices, is it? No it can't be. The Agile Manifesto specifically states "Individuals and interactions over processes and tools." If it isn't about processes what is it?

The more I thought the more agile seemed to be nothing more than agility. Every methodology that I talked about had to do with the ability to change direction at the drop of a hat. Agile is about reaction. Not just any reaction, but ones that cause positive change and outcomes. Agile is about feedback and learning. After all this...Am I agile?

I am agile. I am constantly learning from every source at my disposal. I go looking for ways to improve myself and my product. I adapt to change. I am always trying to push the envelope further. Yet, I can't help but feel that I missing something? What am I missing?

The one thing that I didn't mention above. Is it in there somewhere? Delivering a useable project at any point in development. That is it. That is what I'm missing. This has got to be the hardest part of agile. No matter what we do it always seems that we are one step away from delivering that product at the drop of a hat. If the customer says, "I want to deploy now." I should be able to happily say, "Already done." Not that I don't have software that I can deploy all the time, but what really makes a project "useable?" Can I deliver something that can be let out into the world every week?

That is my goal. From this moment forward I'm going to try and guide my project and my customer so that we are always moving forward with usable software. Not a half done feature at the end of an iteration. I'm going to try and guide the story selection for my projects so that at the end of each iteration we have something to "useable" to deliver. Is it possible?

What is useable? Is this really possible, or is it an ideal that we strive to achieve knowing that it doesn't quite work that way. Once we have the app in production it is easy to keep that way, but is continuous deployment really possible from day zero? Can each commit still be tiny yet completely deployable? What are your thoughts? Also did I miss anything that defines agile, but isn't a practice/methodology?

Code reviews are often abused and executed in ways that drive developers mad, but when executed correctly they strength relationships and skill sets.

Have you ever had your code reviewed and walked away feeling upset or pissed? What was so bad about it? Is there better way that the reviewer could have expressed their feelings?

Have you ever had a great review? Did you walk away feeling smarter and more excited about the project? What did the reviewer do that was so much better than what you have seen from others?

Do you do code reviews? Do you have a checklist that you follow when completing reviews? What things should you watch for when looking through code? Are there any good ways to find the trouble spots in code?

I know I haven't given much except a list of questions, but I'm working on an article and I had to get these out there to help my brain start going. I'd love to hear what anyone has to say on the subject. Thanks.

With some of the moving around of code in Rails 3 Authlogic is broken. This is a quick fix, and not the solution. Add the following to your Session class:

class UserSession < Authlogic::Session::Base
  def self.model_name
    ActiveModel::Name.new(self.to_s)
  end
end

You should be good to go. I have to read up on the process for patching authlogic. Right now it is late and I am sick. I hope this quick fix gets someone going.

I want to have a project that is truly open source. So I thought I would try an experiment. I asked defunkt to completely open legacy_woes up to everyone with a github account. So feel free to commit whatever you want, but try to keep it in the scope of the gem/plugin.