Roman Numeral Kata

While working on the Roman Numeral Kata, I was bothered by the existence of special pairs in my numerals hash.

class Converter
    NUMERALS = { 50 => "L", 40 => "XL", 10 => "X", 9 => "IX", 5 => "V", 4 => "IV", 1 => "I" }
    def convert(number)
        return NUMERALS[number] if NUMERALS[number]
        to_roman(number) 
    end

    private

    def to_roman(number)
        result = ""
        NUMERALS.each do |value, numeral|
            while number >= value
                result += numeral
                number -= value
            end 
        end
        result
    end
end

Notice the 40, 9, and 4. These aren't unique numerals, rather they are pairs that represent special subtraction rules. Doing this gets my tests to pass and solves the problem, but I wanted to see if I could come up with a way that better represented how roman numerals work.

Looking for inspiration, I asked twitter and google for some help, but everything I found either used this technique or did some magic number substitution (YUCK). So I set out to find my own solution. Notice I am not professing I set out to find a better solution, only my own, alternative solution.

I won't be showing all of the tests as we go along, but the entire solution was test driven with RSpec. You can review the history and see the tests on github.

SCNA 2011 Apprenticeship Panel

This year, at SCNA 2011, I had the honor of moderating a panel on apprenticeship. I was lucky enough to get participation commitments from an impressive list of individuals. I feared I would not be able to get a decent panel together and instead, I had to pare the panel from a list of eleven amazing people down to just six.

I want to thank all of the folks who agreed to participate; Shay Arnett, Ken Auer, David Crosby, Zach Dennis, Justin Ghetland, Corey Haines, Dave Hoover, Micah Martin, Robert Martin, Don Mullen, and Matt Yoho. Your commitment to furthering our profession is inspirational.

Audience Participation

We wanted to make sure we got participation from the audience, but also wanted to keep the discussion moving as quickly as possible. We decided to have the audience tweet questions with the #scnapanel hash tag rather than deal with the logistics of getting microphones to the audience or having to repeat every question asked.

As it turned out, this was a fantastic method. Questions that interested several people were retweeted, pushing them back to the top of the queue and I was able to hunt through the questions looking for common themes. This also allowed us to continue the conversation well beyond the panel. Dave Hoover and Ken Auer took the time to answer questions via twitter later that afternoon.

The Questions

As I mentioned, there were a lot of tweets in a relatively short period of time. We had over 300 tweets on the topic with more than 200 of them coming in during the live session.

There were a few common themes; how to select an apprentice, what makes for a good program, and how to get a program started. I've made the entire apprenticeship panel tweet stream available. The following are a few example questions.

• What are the factors you take into consideration when building your apprenticeship curriculum?
• what is the worst mistake you made as a mentor or in your program ?
• does someone ever stop being an apprentice?
• Any formal milestones in your apprenticeship programs? Complete a project, etc.
• Do you also do apprenticeship with existing employees (developers) that might need more training to reach "the next level"?

Continuing the Conversation

I think apprenticeship is a valuable and important undertaking. If the name "apprentice" does not resonate with you, then call it something else. The assigned label is the least important aspect of growing and nurturing our next generations. I invite you to join the Software Craftsmanship google group and engage in the discussion.

Fighting Entropy

It was 1983 and I was in science class when I first heard the term entropy. I don't recall if we were discussing energy conversion, heat as waste, or some other topic wherein entropy plays a part, but I do recall how profound the concept of entropy seemed to me. The notion that there was a lack of order, a lack of predictability, and a gradual decline into disorder resonated with me deeply.

Entropy is the state of existence

I long attributed the phrase "entropy is the state of existence" to my science teacher. Looking back, I suspect that I either misunderstood him or made it up myself, but in any case, the phrase stuck with me and I use it to this day.

For me, entropy is not a fatalistic notion, rather a reminder that all things need tended.

It requires the application of new energy to keep a system at status quo

Disorder is natural and all systems, left un-tended, eventually fall apart. It requires the application of new energy to keep a system at status quo. Our desire to change nothing in order to keep things as they are is unrequited. We must change in order to stay the same.

Entropy and Process

No matter how well your process works today, I can promise you, left unchecked, it will eventually fail to deliver the results it once did. I believe there to be two primary reasons for this. First is that the process in-deliberately changes over time. Second is that our needs for process change as our project evolves and our team matures.

The process in-deliberately changes over time

How many of you have been on a team with stale stand-ups? The format hasn't changed. The participants haven't changed. And yet the value isn't what it once was. We stick to the process and try to recapture the magic.

How many of you have participated in a process that doesn't seem to make sense anymore? When the team started working together, no one knew the system well and there were lengthy debates over what might be true. The code might be complex or poorly covered. It might not.

Our needs for process change over time

Estimating sessions took forever. So management put a silent estimating process in place. This allowed the team to get through estimating sessions quickly. Six months later, everyone had solid experience with the code and was able to articulate real concerns, but the process didn't allow for it. No worries, the process served them well this far; it must be right.

Inspect and Adapt

As a runner, I train regularly in order to maintain my current level of fitness. I vary my training to ensure balance. It requires effort simply to stay the same. And if I want to improve, I must assess my current status, evaluate where improvement is needed, and adjust my training accordingly. If I need to build strength, I work in more hills. If I need to improve my speed, I focus on track work. I monitor my progress to ensure I'm getting the desired results. Pain, fatigue, faster times, improved strength, and no perceivable change are all valuable pieces of information that help me determine if what I am doing is working and what other adjustments need to be made. Invariably, when I stop paying attention, I end up with an injury.

Enter the Retrospective

Retrospectives are the one practice I feel are an absolute must for teams; agile or otherwise. Remember, entropy is the state of existence. It requires the application of new energy to keep a system at status quo. A regular dialogue about what is working, what is not, and what we plan to change is paramount to simple survival. Without it, entropy wins.

Estimating our Work

I've been thinking quite a bit about estimations and our general obsession with getting them "right". After all, we need to know when the project will be done. And we need accuracy. Knowing the entire project will be done before the end of the third quarter isn't good enough. We need to know that the project will be done this month or this week or perhaps even on this specific day.

Through consistency, we attempt to achieve predictability.

I've watched teams put a great deal of effort into improving their estimates. I've seen teams compare stories from this sprint to stories from prior sprints to try to maintain consistency. I've seen teams use a reference story for a single point. When estimating, they look at the reference story and then estimate all others compared to it. These seem like decent practices. The goal of these practices is consistency. Through consistency, we attempt to achieve predictability.

But one thing I've never understood is the notion of estimates versus actuals. Here we look at the original estimate for a story and we then estimate again once the story is complete. The idea here is that the estimate upon completion is an actual. This provides us a learning opportunity whereby we can improve our estimates going forward. This, to me, is a flawed approach. To illustrate my point, let's look at estimations from a slightly different angle.

Estimating Sudoku

"Necessary" Refactoring

In a discussion on the Agile Alliance Linked In Group, Michael Moles asked how refactoring fit into the agile process.

The Question

Refactoring: How does it fit into your Agile process?

We are in the midst of writing a new product, at this point the developers are realizing that some of the code should be refactored to improve performance and or clarity for ease of use. How do you fit refactoring into you Agile process? We have created separate backlog items for refactoring specific pieces of code. These backlog items are treated exactly like any other backlog item (meaning they have effort assigned and are committed to sprints by the team). What do you do when refactoring is necessary?

- Mike

General Consensus

Most folks (myself included) didn't really answer Mike's question. He wants to know how you schedule refactoring when it becomes necessary. But the general consensus seems to be that refactoring is necessary and should not be scheduled. Instead, it should happen as needed.

My Answer