Doc On Dev

Roman Numeral Kata

2011-12-27T10:28:00.002-05:00

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.

Pairing Numerals

After a bit of thought, it occurred to me that I could "pair" numerals. A numeral could be assigned a pair. A numeral and it's pair make a new numeral pair through simple subtraction. For example, five is paired with one. Five's pair_numeral is now 4 with a roman value of "IV".

The numeral class:


class Numeral
    attr_accessor :arabic
    attr_accessor :roman
    attr_accessor :pair

    def initialize(*args)
        if args[0] == args[0].to_i
            @roman = args[1]
            @arabic = args[0]
        else
            @roman = args[0]
            @arabic = args[1]
        end
    end

    def pair_numeral
        return Numeral.new(@arabic - @pair.arabic, @pair.roman + roman) if @pair
        nil
    end

    def ==(compare_to)
        return @arabic = compare_to.arabic && @roman == compare_to.roman
    end
end

I thought later that I don't really need to pass in parameters in variable order and if I do, I could just use a hash, but I didn't get around to cleaning that one up.

The converter class:


require 'numeral'

class Converter
    NUMERALS = { 1000 => Numeral.new(1000,"M"), 500 => Numeral.new(500,"D"), 100 => Numeral.new(100,"C"), 50 => Numeral.new(50,"L"), 10 => Numeral.new(10,"X"), 5 => Numeral.new(5,"V"), 1 => Numeral.new(1,"I") }

    def initialize
        @result = ""
        NUMERALS[5].pair = NUMERALS[1]
        NUMERALS[10].pair = NUMERALS[1]
        NUMERALS[50].pair = NUMERALS[10]
        NUMERALS[100].pair = NUMERALS[10]
        NUMERALS[500].pair = NUMERALS[100]
        NUMERALS[1000].pair = NUMERALS[100]
    end

    def convert(number)
        return NUMERALS[number].roman if NUMERALS[number]
        to_roman(number) 
        @result
    end

    private

    def to_roman(number)
        NUMERALS.each do |value, numeral|
            number = roman_reduce(number, numeral)
            number = roman_reduce(number, numeral.pair_numeral) if numeral.pair_numeral
        end
    end

    def roman_reduce(number, numeral)
        while number >= numeral.arabic
            @result += numeral.roman
            number -= numeral.arabic
        end 
        number
    end
end

This isn't bad, I suppose. Of course, there's a lot more code than the original solution, but it better represents how roman numerals work. Or does it?

The name pair doesn't really make sense. And while I got rid of the special cases in my NUMERALS hash, I call each of them out in the converter class anyway.

I asked friends on twitter to take a look and give me feedback. It was suggested that I change the names "pair" and "pair_numeral" to something else that better expresses what's really happening. So I changed "pair" to "subtrahend" and "pair_numeral" to "difference".

The numeral class:


class Numeral
    attr_accessor :arabic
    attr_accessor :roman
    attr_accessor :subtrahend

    def initialize(*args)
        if args[0] == args[0].to_i
            @roman = args[1]
            @arabic = args[0]
        else
            @roman = args[0]
            @arabic = args[1]
        end
    end

    def difference
        return Numeral.new(@arabic - @subtrahend.arabic, @subtrahend.roman + roman) if @subtrahend
        nil
    end

    def ==(compare_to)
        return @arabic = compare_to.arabic && @roman == compare_to.roman
    end
end

The converter class:


require 'numeral'

class Converter
    NUMERALS = { 1000 => Numeral.new(1000,"M"), 500 => Numeral.new(500,"D"), 100 => Numeral.new(100,"C"), 50 => Numeral.new(50,"L"), 10 => Numeral.new(10,"X"), 5 => Numeral.new(5,"V"), 1 => Numeral.new(1,"I") }

    def initialize
        @result = ""
        NUMERALS[5].subtrahend = NUMERALS[1]
        NUMERALS[10].subtrahend = NUMERALS[1]
        NUMERALS[50].subtrahend = NUMERALS[10]
        NUMERALS[100].subtrahend = NUMERALS[10]
        NUMERALS[500].subtrahend = NUMERALS[100]
        NUMERALS[1000].subtrahend = NUMERALS[100]
    end

    def convert(number)
        return NUMERALS[number].roman if NUMERALS[number]
        to_roman(number) 
        @result
    end

    private

    def to_roman(number)
        NUMERALS.each do |value, numeral|
            number = roman_reduce(number, numeral)
            number = roman_reduce(number, numeral.difference) if numeral.difference
        end
    end

    def roman_reduce(number, numeral)
        while number >= numeral.arabic
            @result += numeral.roman
            number -= numeral.arabic
        end 
        number
    end
end

Now it is obvious that we are subtracting the subtrahend from the minuend in order to ascertain the difference. Right?

Right?

Damn. Still doesn't "feel" right.

I'm trying it again. Stay tuned.

SCNA 2011 Apprenticeship Panel

2011-11-18T16:44:00.001-05:00

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

2011-08-21T20:31:00.001-04:00

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

2011-05-24T16:15:00.002-04:00

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

Indulge me for a bit here. Writing code is really problem solving. Sudoku is (clearly) problem solving. Admittedly, sudoku is far more simple than writing code. Simple in terms of strictly constrained and with very few possible solutions (often one solution). If we can agree that sudoku can serve as a simple model for writing code, then please do read on.

I have a sudoku game on my phone. It breaks the games down into four categories; easy, medium, hard, and expert. Clearly, the games are all on the same size grid with the exact same rules. The difference between these games is merely the number of seeded answers and their locations on the board. These two factors make a game more or less difficult to solve. I don't know that a medium is twice as difficult as an easy, but I am certain that a medium is more difficult than an easy.

Actuals

I've played hundreds of sudoku games on my phone. I've played each level of difficulty at least 50 times. And the game has tracked my actual time to complete for every play. The following graph shows the time to complete for 40 games at each skill level. The y-axis is the time to complete. The x-axis is the number of games.

At point 6 on the x axis, the easy story takes nearly 8 minutes to complete. This is well outside the normal effort for an easy. In fact, it exceeds the average for a medium. After completion of this puzzle, were you to have asked me, I might have concluded that it was actually a medium or even a hard. But the truth is, it was an easy. For some reason, I struggled to solve it. Maybe I missed a subtle clue. Maybe I made a mistake that sent me down a wrong path for quite a while. I honestly don't recall. But the amount of effort it took me to determine the solution does not change the quality of the puzzle itself.

It didn't become an easy puzzle just because I found it easy to solve.

Similarly, there are a number of times where I managed to complete expert puzzles in times consistent with a medium or even an easy. Again, this does not change the fact that the puzzle was an expert level puzzle. It didn't become an easy puzzle just because I found it easy to solve.

Back to software

Looking at the variance in simple sudoku puzzles, I hope we can agree the same kind of variance is perfectly reasonable in software development. An estimate of 1 point indicates the team agrees this is a story of relatively low complexity and that it is similar in complexity to other stories that we previously agreed were also 1 point. An estimate of 1 point does not directly indicate that it will take a specific amount of time (or less). An estimate of 1 point does not necessarily indicate that it will be faster to complete than a 2 point or 3 point story. On average, a 1 point story will be completed in less time than a 2 or 3. On average.

A 3 point story doesn't become a 1 point story just because you completed it quickly.

There are times when a story changes. Say certain requirements are dropped or we discover that we'd already written some of the code months ago. I am sure there are other reasons. But just because a story took longer or shorter than the average time to complete similarly sized stories does not mean the story was improperly sized. A 3 point story doesn't become a 1 point story just because you completed it quickly.

It's All Relative

I recommend you use a reference story. Identify a story that the entire team can agree is 1 point. When you are estimating, keep that story in mind and attempt to estimate all others relative to it. Then, at the end of the estimating session, compare the stories to one another. Do the points still feel right? Compare the stories to random selections from prior iterations? Do the points still feel right? If not, make adjustments to your new estimates as necessary.

"Necessary" Refactoring

2011-04-06T06:49:00.001-04:00

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

In my mind, there are two types of refactoring; real-time and planned. In each case, we are changing the implementation without altering behavior. In each case, we need comprehensive test coverage. Without tests, we don't know for certain if we've altered behavior or not.

Real-time refactoring is a great behavior to cultivate. It is a natural part of the TDD flow. Red => Green => Refactor. We are continually looking for small ways to improve the code; rename a variable, extract methods to create a composite method, generally make the code readable, DRY, and well composed.

Planned refactorings tend to be larger chunks. We've realized the need create a base class and derive from it rather than have this complex conditional. We see now that we have a lot of responsibility in the wrong place and need to re-work a section of the code to reduce coupling.

Following TDD practices, we tend to have more real-time refactoring and less planned. This is good. It means the code is generally better composed. We are keeping it clean as we go along rather than letting it get bad and then asking for permission to clean it up.

Many agile teams adopt the practices of TDD and ATDD to ensure they can deliver working software and respond to change. For those teams, refactoring is a given.

Values and Beliefs

2011-03-15T17:44:00.000-04:00

Earlier this week, Bob Marshall (@flowchainsensei) retweeted an article by Dan McCarthy on The Meaning of Respect, where he discussed respect as a value. I then saw a blog post from Seth Godin entitled "Seven Questions for Leaders" where he asks if you would walk away from a client or employee whose values don't match yours. This weekend, at Agile and Beyond, I got into a conversation with several others about company values and walking away from clients when there is a mis-match. At LeanDog, we proudly display our company values and we often refer to the XP values of Simplicity, Communication, Feedback, Respect, and Courage.

I've long held the perspective that shared values is an insufficient basis for determining if two parties are compatible. In fact, it can be downright misleading.

Our beliefs are a better test, but often more difficult to identify.

Family First

Before they were married, Tom and Janet had several late night discussions about what their future would look like. They agreed they wanted children and above all else, family had to come first. "Family First" became a mantra in the early years of their marriage. They both worked hard and rather than taking vacations, they saved and invested, waiting for the day they had their first child.

With the arrival of Jacob, their first baby, they talked and agreed that Tom would quit work to take care of the household while Janet continued to work. Janet had a more significant income and a better benefits program. This was a simple decision for the two of them. "Family First".

But shortly after the baby arrived and Janet returned to work, things started to take a turn. Tom found himself and the baby eating dinner without mom as she worked extra hours. Janet often brought work home and while she spent some time with the little one, much of her time at home was dedicated to work.

The strain took its toll and Janet and Tom found themselves arguing over petty things. The months passed and the resentment built.

One evening, after a particularly trying day, Tom sat down to relax for a moment with Janet before bed. She had her laptop open and was instant messaging with someone from work.

"You know", Tom blurted, "you say 'family first', but you're never here. Even when you are here, you're not here."

"How dare, you?", Janet responded, "I work for the family. I make money for the family. Everything I do is for the family! How can you possibly say I don't put family first after all the sacrifices I've made?"

"Sacrifices? Sacrifices? You're never here. You don't clean up the mess. You don't do the laundry! You don't do anything for the family, except help put Jacob to bed and put a check in the bank. I have to do it all."

"Of course I put a check in the bank! You don't work at all. You haven't even picked up a part-time job. You won't even consider putting Jacob into day care a couple days per week to help with all of this pressure. I have to do it all."

Shared Values

Tom and Janet agree on the value of "Family First". Neither of them is lying about that. Both of them are living those values. So how is it that it has come to this even before Jacob's second birthday?

Differing Beliefs

Tom believes that "Family First" means you spend time with the family. Play time, limited work hours, keeping the home, educating your children, and just being a supportive family to your children. Tom has made great sacrifices to live true to his values and he wants Janet to do the same.

Janet believes that "Family First" means supporting the family. Doing what it takes to provide them with the best schools, making sure they are provided healthy foods, providing a safe house, offering them a promising future, and being a support system for your children. Janet has made great sacrifices to live true to her values and she wants Tom to do the same.

Beliefs are held to be true

The boiling point of water is 100 °C (212 °F) at standard pressure. This is a fact. It is true.

Good parents spend ample quality time with their children. This is a belief. It is often held to be true, but that does not make it a fact.

We evaluate the behaviors of others by contrasting them with our values and beliefs. When someone says they share our values, we expect they will behave in a congruent manner. But that manner is shaped by our beliefs. Beliefs which they unlikely hold in the same degree and manner.

Consider your own beliefs

Do they serve you well? Are they moving you toward or away from the things you hope to achieve? Why do you hold these beliefs? Could you change them?

Consider the beliefs of others

Do you know what they are? Can you accept them as valid from that individual's perspective? Does understanding a person at this level help you to better communicate with them? Better understand them? Better love them for who they are and not for who you want them to be?

I think so.

Stabilizing Velocity

2011-03-10T09:30:00.000-05:00

Have you ever been on a team where your velocity suffered wild variances? Maybe you ended up using a running average instead of yesterday's weather?

Have you heard phrases like, "Well, our velocity last iteration was 3, but our average is still 22"?

Have you ever heard the phrase, "Dude, we need to get this velocity stable."

Have you worked on teams where they took partial credit for done at the end of the iteration? Where maybe you'd split a card strictly on points and award some apportion to the current iteration and assign the remainder of the card to the next iteration.

Velocity should stabilize

It seems much of what we read tells us that velocity will do two things; stabilize and improve. According to the VersionOne Agile 101, we can expect that velocity will stabilize within three to six months. The Agile Sherpa tells us it usually takes 3-4 iterations for velocity to stabilize at a consistent level. James Shore's "The Art of Agile" tells us to give it three or four iterations to stabilize.

But what if velocity doesn't stabilize?

First, take a deep breath; and then repeat after me:

If you have an erratic velocity, it is telling you of a problem. And your problem is not an erratic velocity.

"Velocity is a health indicator. Velocity is a health indicator. Velocity is a health indicator. Velocity is ..."

Velocity lets us know how things are going. It reveals issues to us in sometimes subtle ways.

Think of velocity as heart rate. An abnormal heart rate, be it too fast, too slow, or irregular can indicate a number of underlying issues such as electrolyte imbalance, overstimulation, insufficient rest, autoimmune disorders, thyroid problems, or various forms of heart disease. If you have an abnormal heart rate, it is telling you of a problem. And your problem is not an abnormal heart rate.

An erratic velocity can indicate a number of underlying issues such as poor story composition, dependencies on other teams or individuals, too much work in progress, silos, and various forms of mismanagement. If you have an erratic velocity, it is telling you of a problem. And your problem is not an erratic velocity.

Whatever the underlying problem, it is something you can adjust. Adjustments for which you can observe the outcome. But the important thing to remember is that the velocity is not the problem. Do not try to fix the velocity. Try to figure out what it is telling you and fix that.

What should I adjust?

...poor story composition, dependencies on other teams or individuals, too much work in progress, silos, and various forms of mismanagement.

If an erratic velocity could be telling me any number of things, then how do I know what to adjust? Ask your team. They probably know. They may not know they know, but they can give you indicators.

Let's look through some of the common underlying causes.

Poor story composition

By story composition, I mean story size and dependencies. The larger the story, the more risk there is of getting it to done. But it is not just about making stories small. It is about making them small and independent. Small stories that cannot be delivered independent of one another are really just tasks for a large story.

If we have an issue with proper story composition, we may find we get several stories close to done, but we cannot run acceptance tests on them until all of them are complete, leaving us with too much testing at the end of the iteration. It we don't get all of the stories ready, none of them can move. Then, next iteration, we complete the last strays and a glut of cards/points move to done. Alternatively, some stories are just too big to complete in a single iteration.

Mike Cohn has a number of good resources on creating user stories. There is no need to get your stories perfect up front. Get them good enough to do a high-level estimate; think epics. Then as you start planning releases, break them down into features to get a finer-course estimate. Finally, as you plan iterations, break them down again into small, independently deliverable items. Beware the temptation to split stories across technical seams. Instead, focus on small stories that are thin vertical slices through the technology stack.

Dependencies on other teams or individuals

Perhaps your product owner is not available often enough and there is too much re-work due to slow feedback cycles. Maybe you haven't rights to your various environments and code migrations are executed in durations of days rather than minutes. It's possible some other technical team is not able to be as responsive or relies on process more than interactions for the exchange of information. Whatever it might be, any point where you need to wait for extended periods of time, is likely to lead to other problems. You can't sit idle, so you grab another card to work on, leading to too much work in progress.

Work with these teams and individuals on ways to automate processes or find other ways to reduce their response time. Invite sponsors and others to your stand-ups, iteration planning, and retrospectives. If they consistently don't show, see if you can get another representative. Be professional and courteous, but there is no need to be completely deferent. If the project is important, you should be able to ask for the necessary support.

Too much work in progress

This is a remarkably common issue. In my experience, management often encourages this behavior. I don't know if it is the notion that we will get more done if we work on more things simultaneously. Or perhaps there is a fear we won't get enough things done unless we work on several of them at once.

But what happens when we try to work on a few stories each? Remarkably, we make progress on several, but complete precious few. The more work in flow, the more context switching we all need to make. Coordination of the stories complicates testing and migrations. We look busy, but at the end of the iteration, we've fewer things complete. Then, at the beginning of the next iteration, a glut of work moves to done, setting us up with a couple day delay wrapping up the prior iteration and pushing us into yet another complicated cycle.

Drive each card to completion before picking up the next one. If a card is blocked, make getting it un-blocked a priority rather than letting it wait three days because George on the DBA team has a three-day SLA.

Silos

Most teams I work with have three distinct roles; BA, Developer, and QA. Most teams I work with have three distinct phases of their work; gather requirements, build, verify. Even on agile teams, these separations exist. There are clear delineations in the process and clear segregation of responsibilities. But this segregation is a contributor to erratic velocity. How many "agile" teams do you know of where the BA group is an iteration ahead of the developers who are an iteration ahead of QA, leaving us with a three-iteration cycle time and significant lag in our feedback loops between the groups?

Tighten the loops. Get people working together in not only close proximity, but close time-frame. Involve the developers and QA in the formation of requirements. Push QA to the front and automate, automate, automate. Don't let manual testing be a bottle neck. Start development before you've polished the requirements. And don't wait until the end to test it all comprehensively.

Various Forms of Mismanagement

Herein lies my primary onus for the mantra, "Agile ain't practices". Agile is a set of values.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Address the actual problem and use velocity to tell you if you have, in fact, done so.

I see organization after organization pick up practices in the name of agile and apply them devoid of the values. Most popular seems to be daily stand-ups and burn-down charts; two tools that provide project management quick feedback on status so that they can make informed decisions about items such as task assignment or if the team needs to put in extra hours to make the deadline. (By the way, that sentence should make you cringe)

Assigning tasks, driving for excellence in estimating, pushing for points, treating code as if it is only a means to an end, role-based incentives, making the team's decisions for them, leaving the team to make all the decisions (they are self-organizing after all), splitting people's assignment across teams (they only need 1.5 QA), burdensome process, and failure to address impediments are but a few examples of mismanagement.

Don't mess with the math

Don't split cards on points and award some apportion to the current iteration and assign the remainder of the card to the next iteration. I am confident this will normalize your velocity. Much like taking cough medicine subdues your cough. Neither of them cures the real problem. They merely hide the symptoms in hopes the real problem will run its course. Erratic velocity is the result of issues that, left unaddressed, are highly unlikely to run their course.

Address the actual problem and use velocity to tell you if you have, in fact, done so.

Open iTerm Here

2011-02-26T15:31:00.002-05:00

I've been using iTerm for over a year now. I like it over Terminal for a few reasons, but primarily because it supports multiple frames. This makes my workflow easier as I can see everything on a single screen and can easily navigate from one frame to the other without reaching for the mouse. I've additionally abandoned MacVim for Vim. Now, I can do most everything I need in a single, maximized, iTerm window. But I get annoyed with opening iTerm and having to navigate to the directory of my current desire. Most of the time, I am already browsing the desired directory in Finder as I begin a hacking session.

What is a guy to do?

AppleScript to the rescue

I created an AppleScript app based on work from a couple of other folks, whom I've given attribution. The AppleScript launches iTerm and changes to whatever directory was active in Finder. If iTerm is running, the script opens a new terminal. If iTerm is not running, the script launches it and changes directories accordingly.

You can use the script for yourself.

Paste it into the Script Editor application and save it as an application
In Finder, navigate to the application and drag it to the Finder bar
You can now click the button and it will open the foremost directory in Finder
Or you can drag and drop folders onto the icon
Locate iTerm and Select the More Info... button
Locate your new app and Select the More Info... button
Copy the small icon from the top-left of the iTem Info window
Paste it onto the small icon of your app's Info Window

Telling the complete story

2011-02-14T11:00:00.002-05:00

Decomposing the story format

Working with several clients, I see differing story formats. The format I see most recommended is "As a, I want, So that". The format I see most utilized is "I want". Isn't this the important part of the story anyway?

I think not. Let's look at the three components: As a, I want, and So that.

As a

This tells us whom the story is for. If we've developed personas or identified our users in some other detailed capacity we probably have a sense of who this person is and what motivates them. If not, we probably have a vague sense of who this person is and are likely to assume they are much like ourselves.

I like personas. I like real people even better. But let's be honest; fabricated or real, these people are representative of a larger group. They are a generalization whose primary purpose is to help us understand what motivates the group. In other words, we get to know them so that we can empathize and better understand the problems they need solved.

I want

This tells us what we anticipate will address our need. If we've followed good usability practices or have done sufficient research we probably have a sense of how likely this is to solve the problem. If not, we probably have a vague sense that this is an appropriate solution and are likely to base the answer on what we've seen in other solutions.

I am a proponent of user centered design. The more we get users engaged, the better our solution. But the truth is, the "I want" is a guess that will only be proven once tested with real users, in our real application, in the real world.

So that

Ah, and here we are, at the crux of it. This is the problem we are trying to solve. The other two components of the story are supporting cast to this, the main character. Why is it that we tuck our star away at the end of the script? I do not know. I've previously suggested people change their story format to "So that, As a, I want" in order to focus more on the value and less on the means.

We frequently miss the point

I often see story cards that miss the mark in subtle ways. Consider the following:
"As an account manager, I want a listing of accounts, so that I can see them on the page."
"As a member of the support team, I want to track membership updates, so that I have a history of the changes."
"As a marketing manager, I want to enter testimonials, so that visitors can read them."

These stories adhere to the format, but they don't tell the complete story. We don't really know what business problem is being solved. Perhaps we can infer the problem, but there are likely to be vastly differing opinions. If we don't know what problem we are solving, we have no idea if the solution is valid.

A story that fails to tell us the problem misses the point.

Tell the complete story

Let's take a look at how these stories might read after a little more consideration given to the fundamental issue we are trying to resolve.

"As an account manager, I want a listing of accounts, so that I can quickly access any of my accounts."
"As a member of the support team, I want to track membership changes, so that I can identify potentially fraudulent accounts."
"As a marketing manager, I want to enter testimonials, so that prospects can see that we have satisfied customers."

These re-worked stories, while certainly not perfect, now tell us what problem we expect to solve. This gives us an opportunity to have a deeper discussion. Does the "I want" satisfactorily resolve the fundamental need described in the "So that"?

Given these final stories, I expect at least one team member would question the identified solutions. How many accounts does the average user have? Is a listing an appropriate way to access accounts? How would we identify fraudulent accounts? What data should we track and are there patterns we should monitor for in the code?

These discussions are good. They mean we are focused on the right things and we are thinking about delivering solutions, not features.

Pairing is Conversation

2011-02-02T12:00:00.000-05:00

I really enjoy pair programming. It seems a natural process to me and I often wonder why it is that I like it so when others may not. Clearly, we have differing tastes and styles. I am sure that contributes to the joy (or lack thereof).

I've been watching others pair lately. And there is something I've noticed; pairing done well is conversation.

What makes a conversation?

A conversation is communication between two or more people. For a successful conversation, the participants need to achieve a workable balance of contribution on a mutually agreeable topic. Conversation is indispensable for the successful accomplishment of almost all activities between people, especially the coordination of work and for learning.

Pairing can involve all four elements of human communication; Non-Verbal, Visual, Oral, and Written.

Human communication is comprised of four elements; Non-Verbal, Visual, Oral, and Written. In order for there to be a conversation, we require more than one participant and at least one form of communication. Communication is achieved when the receiver of the information understands the sender.

What makes a good conversation?

A good conversation involves participants who are genuinely interested in the topic, are informed in various ways, and are respectful of one another. Characteristics of a good conversationalist include being genuinely interested in the topic, listening to the other participants, giving the other participants time to think and respond, and considering the input of others before responding.

What makes a pairing session?

A pairing session takes place between two or more people. For a successul pairing session, the participants need to achieve a workable balance of contribution on the story or feature being delivered.

Pairing can involve all four elements of human communication; Non-Verbal, Visual, Oral, and Written. At a minimum, written is required in the form of code. Code is written in languages. It is a means of communicating intent to both the programmers and the computer. Our pair provides non-verbal cues through their body language, visual cues by writing, drawing, or pointing to the screen, and oral cues by telling us what they are thinking and doing or responding to what it is we are thinking and doing.

What makes a good pairing session?

A good pairing session involves participants who are genuinely interested in the story, are informed in various ways, and are respectful of one another. Characteristics of a good pair include being genuinely interested in the work, listening to the other participants, giving other participants time to think and respond, and considering the input of others before responding.

Participating in the Conversation

I've been involved in numerous pairing sessions throughout my career; some excellent, some terrible. Just as conversations, you need to know when it is working and when it is not. Just as with conversations, you need to participate if you want to get anything out of it.

For me, an ideal pairing session is absorbing. My pair and I start with a discussion, perhaps it is one of us getting the other up to speed. Maybe it is a brief review of the problem and what our next test should be. It might be how to approach a large refactoring.

I'm not going to say you're doing it wrong, but I am going to say I think you're missing out on a fantastic experience.

At some point, one of us starts typing. Who is typing doesn't matter. Often, who was typing is completely unclear. The exchange continues, both of us talking, both of us typing, the solution evolving before us as we go.

When we are done, neither of us can really recall who was typing when or which one of us came up with more of the solution. And it doesn't matter. We just had a great conversation.

Try it for yourself

If you're pairing and there is little verbal communication happening, I'm not going to say you're doing it wrong, but I am going to say I think you're missing out on a fantastic experience.

And how do we get to the place where we don't know which of us is typing? Easy - two keyboards and two mice for each computer. There is no need to hand a keyboard back and forth. The exchange of the token kills the flow. If we agree that two people on a single machine is optimal, why wouldn't we have two sets of input devices?

The next time you pair, start with a keyboard and mouse for each of you, then begin talking about what you want to do. See where it goes from there.

I know for me, the best pairing sessions are simply good conversations.

A good coach seeks first to understand

2011-01-24T13:00:00.005-05:00

Journeyman Jones, a journeyman carpenter is called upon to train a team of aspiring apprentice carpenters at Gable Gates. On the first day, Journeyman Jones sees that the apprentices are all striking nails with the broad-side of the head instead of the intended business end.

Confusion

"What on earth are you doing?", exclaims Jones.

"What do you mean? We are framing a house.", replies one apprentice.

"Yes, but why are you using your hammer like that? It is wrong. No carpenter would ever do that."

"But this is how Master Smith taught us. He was passing through and showed us to hammer this way."

"Master Smith?", asks Jones incredulously. "Impossible. Master Smith is one of the finest master carpenters around. He did not tell you to do that."

"But, he did." insists the apprentice.

"No matter.", says Journeyman Jones, "Let me show you the right way."

And so he does.

Concern

Days later, Jones confirms that Master Smith had in fact visited the apprentices only weeks before. Maybe it is true. Maybe Smith did teach the apprentices the wrong way to use a hammer.

After considerable thought, Jones decides, "The old man must have gone crazy. I need to tell people about this."

The next day, he tells the apprentices of Gable Gates, "Master Smith has lost his way. He's forgotten the very basics of our trade. Should he pass here again, be polite, but do not listen to what he tells you. Smith is no longer fit to teach proper carpentry."

Understanding

Many weeks later, while at a conference, Journeyman Jones happens an opportunity to speak with Master Smith.

"Master Smith, may I bother you with a question?"

"You just have.", replies Master Smith. "And I will grant you another." Smith smiles, indicating he isn't bothered in the least.

"I understand you taught the apprentices of Gable Gates."

"Yes. But only briefly. I was merely passing through."

"They insist you instructed them to strike nails with the broad-side of the hammer head. But I am sure that couldn't be so."

"I did instruct them to do just that.", Smith says in a matter-of-fact manner.

"But", stumbles Jones, shocked by the tone more than the confirmation, "I don't understand why you would do such a thing. With all due respect, that's just wrong."

"You see," says Master Smith, "when I first happened upon them, they were tying the framing together with twine. After some discussion, I understood they had quit using the hammer because it damaged the wood every time they missed the nail. Knowing you would be by only two weeks later, I showed them how to use the broad-side of the hammer head to increase the surface area, reduce the likelihood of a miss, and allow them to practice hammering. With two weeks of practice, they would be ready for your instruction. And were they?"

"Yes.", replies the journeyman, "They were. Thank you for setting them on the right path. And now I must ask your pardon, but I need to return to Gable Gates immediately. There is one more instruction I must give them."

Sharpening the Saw

2011-01-24T10:34:00.017-05:00

I like to practice my craft. I enjoy participating in Code Retreats. I enjoy facilitating Code Retreats. I like working on kata and koans. And a lot of what I talk about includes references to these practices. We at LeanDog are always on the lookout for people who are passionate about improving their own craft. I thought I'd start a blog entry where I catalog resources that might be of interest to others looking for ways to sharpen their saw.

Please feel free to reply to this post with other resources I don't have listed. I will try to keep it up to date as I discover more.

Programming Exercises

Pragmatic Programmers Code Kata

A collection of Kata from the folks over at Pragmatic. As of 24-Jan-2011, there are 21 different kata listed on the site.

You can also find information about kata, koans, kumite, and the Dreyfus model. All interesting topics and worth looking at.

Coders Dojo

There are no kata listed on this site, but if you are interested in kata, you need to know about this one. Coders Dojo provides an on-line live dojo for Ruby. You can execute the kata in the browser. Alternatively, you can run the kata on your local machine. In either case, you can then share the kata with other members of the site and get feedback. They have support for several other languages.

CodingDojo

There are approximately 25 different exercises on this site. They are broken down into categories; Algorithmic, Game Modeling, Math Oriented, String Manipulation, and Specific Technologies.

Coding Kata

Over 20 kata are listed here. This site is nice for the beginner. The first kata is a Hello World that walks you through the steps of setting up a java development environment. They provide steps for several languages, all of which run on the JVM. You can choose from Java, Groovy, Scala, Clojure, JavaFX, Jython, and JRuby. They also have a javascript option.

Ruby Quiz

While listed as the Ruby Quiz, the problems listed here can be done in any language.

There are 156 challenges listed here, so there is plenty to keep you busy for quite a while. Many of them are also available on other sites.

Project Euler

Taken Directly from the Project Euler site:

Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems.

Programming Praxis

The sub-title of the programming praxis site is "Sharpen your saw". I discovered this after I named this post.

There are over 200 programming challenges on this site. You can find listings in chronological order, by themes, or through a search mechanism. Much of what is compiled here is available on other sites as well, but there are several unique challenges to be found here.

Sphere - the mother of them all?

There are over 8200 various programming challenges on this site. This is by far the most comprehensive collection of programming challenges I've found thus far.

TDD Problems

Thanks to George Dinwiddie for pointing this one out. TDD Problems is a listing of approximately 30 (so far) that, according to the site's authors, meet the following criteria:

they are real-world, not just toys
they are targeted towards learning TDD (that is: they are small and easy enough to work out in say half a day)
they don't involve any of the harder-to-test application development areas: GUI, database or file I/O. (since those topics are considered too hard for the TDD-beginner)
they have been solved by a TDD-practitioner previously, proving their appropriateness for [the] site

Carnegie Mellon Craftsmanship Katas

This list of kata is from the Carnegie Mellon University - Silicon Valley curriculum. If you are not familiar with this program, I suggest you look into it. If you've a child considering a major in computer science, this unique program is teaching students how modern software is developed.

The Gilded Rose Kata

This kata made the rounds on the Software Craftsmanship Google group. It is in C#, but could easily be recreated in your language of choice. You will want to get the source for the kata off of NotMyself's github account.

There is another version of The Gilded Rose Kata available from Terry Hughes.

Code Brawl

CodeBrawl is a series of coding contests. You can subscribe to the feed and get notified when the next contest starts. If you prefer to take your own sweet time, you are free to try out any of the prior contest challenges; create your own testing library, a diff tool, or a command line todo tool among others.

Koans

A koan is part of the Zen Buddhist lore and history. It is essentially a question or story that is not understandable through rational thought, but may be through intuition. Teachers of Zen practices may ask students about the koan practices through checking questions. These questions are intended to validate insight or awakening. - borrowed liberally from wikipedia.

As far as I know, EdgeCase was the first to create a set of programming koans. Today, there are koans available in numerous languages. These are all entertaining and educational.

Ruby Koans

The Koans walk you along the path to enlightenment in order to learn Ruby. The goal is to learn the Ruby language, syntax, structure, and some common functions and libraries. We also teach you culture. Testing is not just something we pay lip service to, but something we live. It is essential in your quest to learn and do great things in the language. - from the EdgeCase Ruby Koans site.

Clojure Koans

One of the first in a series of functional koans, this was started by Aaron Bedra at CodeMash 2010. Now maintained by Colin Jones, the Clojure Koans are the work of several excellent contributors.

JavaScript Koans

Inspired by the Ruby Koans, Liam McLennan brings us the koans for JavaScript. The JavaScript koans go on to cover equality & “truthyness”, assignment, control structures, strings, numbers, objects, arrays, scope, and regular expressions.

OCaml Koans

The koans here are in a significantly different format from the Ruby and Functional koans already listed. This is a page of koans in the more classic sense. There are stories that are intended to help one learn functional programming concepts.

Smalltalk Koans

Thanks to Steve Kim (@skim) for pointing these out and even more so for authoring them. If you are not familiar with smalltalk, you might want to give it a look. What excites you about modern day languages like Ruby or Python can likely be found in smalltalk.

Testing Exercises

It is awfully difficult to deliver good software without testing; "nigh impossible", one might say. Actually, I don't really know anyone who would say that, but it doesn't make it any less valid. Thanks to Markus Gärtner for giving me the first two entries for this section. I hope to add more.

Testing Dojos

This site is designed to help you run a testing dojo. It provides details on the equipment, roles, and mechanics. It covers types of dojos and discusses the value of reflection at the end of each dojo. There is also a small list of Public Dojos available. The dojo list is segregated into conferences (short-term) and locations (long-term).

Testing Challenges

There are more than 50 different testing challenges available on this site. The setup and description for most of the challenges is pretty brief, but it is sufficient to get you started. There are links to sites with more details and/or the code that will be under test. One especially nice feature is the "Similar" button on each page; click it and get a listing of exercises that are similar in style or approach to the one you are currently viewing.

Squirrel!

2011-01-22T11:56:00.001-05:00

I've made a pretty significant change to the way I work on my laptop. None of what I'm doing is unique, but I think it is going to help. Before I get into describing the changes I've made, I thought I'd share a bit of the back-story.

Stupid Car...

This week, my car broke down and through a series of unfortunate events, I spent the entire day alone in my apartment. I decided to work on stuff and things. I waffled a bit about whether I should start on the stuff and get it taken care of, or do the things and let the stuff wait. And then I just sort of started doing; no plan, no pomodoro. I just meandered from item to item.

As the day was wrapping up, I realized I had completed neither the stuff nor the things. In fact, I couldn't really account for the hours that had passed. I worked a bit on this. I worked a bit on that. I had plenty of time. How could I have accomplished so little?

Bring me one more browser

The next day, I picked up my car from the shop and I headed to the LeanDog boat. Dave Hoover was giving a talk on apprenticeship. I wanted to get there early to see Dave before the event.

Much to my delight, not only was Dave on the boat, but several others were there. Joel Helbling was pairing with Dave on Conway's game of life. Kevin Solario and Joe Fiorini were talking over a project they've been working on. Jonathan Penn was working on the next great NavelLabs release. And Ben Woznicki was soaking it all in.

I eventually sat down with Joe Fiorini to learn a little more vim-fu. As we were working our way through the installation of various extensions and exploring their use, I popped open Opera to get to one of the sites.

"What browser are you using?", Joe asked.

"Opera.", I said

"What?"

"Opera. I don't use it all the time. I ran out of browsers."

"What?"

"I have mail and calendar and stuff in FireFox and I'm reading the things in Chrome. I'm using Safari for an app I'm working on. So I'm using Opera to surf around."

"What?"

What indeed.

Jonathan Penn OH'd me. I deserved it. Seriously? What was I doing right now? I was running vim in iTerm2 and I was updating my ~/.vimrc file. Did I need four different browsers open let alone however many tabs were anxiously awaiting but a moment of my attention? What about twitter and skype and basecamp and irc?

Yikes! Squirrels everywhere.

Pomodoro helps keep me focused, but I sure could use a few less distractions as well.

Let's see how this goes

I switched to MailPlane to start off. Rather than using two different browsers to manage my primary email accounts, I now have one app where I can quickly switch from account to account. And more important, I can close the whole damn thing quickly with a single Cmd-Q. I can open it nearly as fast thanks to Alfred. Now it does not sit open all the time. I open it when I intend to check mail and I can get the mail taken care of quickly with nary a reach for the mouse. Two squirrels down.

I then wrapped several apps in fluid. I have an app for my blog which opens two tabs; one to see the stats and one to manage posts. I open it when I am working on my blog. I keep it closed otherwise. One more squirrel gone. I also put BaseCamp in a fluid wrapper. Then GitHub. Then I created one that contains both LinkedIn and FaceBook and called it Social Networks. Four more squirrels eliminated.

I now run with two spaces down from six. I have twitter and skype open in one. I open whatever I am currently working on in the other. Everything else is closed. I'm thinking about reducing it down to a single space and running twitter and skype minimized.

Duh

It was certainly one of those moments. I talk to people all the time about limiting your WIP, paying attention to cycle time, working within time-boxes. And here I was, meandering through the fields of my own work, moving from squirrel to squirrel wondering why I wasn't getting anywhere.

Thanks Joe and Jonathan. Thanks for making fun of me just enough to allow me to see the absolutely ridiculous behavior I was engaged in.

I hope someday I can return the favor.

Would you be willing to preach what you practice?

2011-01-17T10:00:00.002-05:00

There's an old saying

Practice what you preach

Practice what you preach is a variation of Practice yourself what you preach. I think we are all familiar with the phrase. I suspect most of us understand the basic sentiment upon first read.

This phrase addresses hypocrisy. It originally spoke to those who demanded others be pious while themselves partaking in sinful activities. It certainly applies to anyone whose personal life is lived in a manner incongruent with the values and behaviors they publicly espouse.

But what if you don't preach?

While hypocrisy is certainly distasteful and ugly, most of us are more challenged by what we do and don't openly talk about. Most of us don't preach. Most of us don't presume to publicly tell others what to do, especially if we feel our own behavior is less than exemplary.

But does failure to be a public hypocrite justify unsavory behavior? Is it acceptable to act in a reprehensible manner so long as you don't tell others they shouldn't?

It's not personal, it's only business

I've heard this phrase a few times in my career. I loathe this phrase. Business is nothing if it is not personal. The people who have uttered this phrase to me did so without hesitation. At the moment they said it, they genuinely believed it. They were backing out of a handshake agreement, laying off people to increase their own bonus, or flat out lying to a business partner. Business to them, was about money and nothing else.

But had they been asked to, would they stand in front of a crowd and condone lying or cheating to make an extra dollar? Would they advise others to behave this way if they knew it was being recorded for posterity to be played back in every future job interview? I doubt it. While they may live this way, they wouldn't publicly admit it.

What do you want me to do, crack your skull open and pour knowledge into it?

I was in the room when a former boss of mine said this to a new employee. The employee was asking about a set of instructions for configuring a modem. Our boss had written the instruction set and was "training" the new employee on proper procedure. They had spent much of the day together and the employee, as might be expected, had several questions. This particular question was a legitimate suggestion for improvement masked as an inquiry. But the content of the question didn't seem to matter. It was one question too many for the manager to handle.

Would this manager blog about yelling at employees as a proper method to keep them in their place? Would this manager be willing to teach an introduction to management course where berating and insulting your employees was encouraged? Certainly not. In fact, he considered himself quite the benevolent dictator.

Lie and deceive in order to build trust

I was not new to management, but I was new to management at this particular company. I found the politics especially difficult to navigate. This was a particularly difficult environment for me to work in. A peer and I used to go for runs at lunch. We'd talk the entire time and while discussions were often about training techniques or local races, we would occasionally talk about work. During one work related discussion, I asked him how he dealt with the politics, lack of good leadership, and other issues plaguing our ability to deliver.

"I tell them what they want to hear and then I do what I know needs to be done. I don't give status unless I'm asked and I don't give it in writing. Most projects die around here for other reasons. As long as they think I'm on schedule, I don't get blamed."

I thought about it for a while and I said, "So you lie to them."

"You can't do it all and nobody wants to hear the truth."

Would his Master's Thesis be "Lying as a necessary path to success"? Would "Lie to your customer" become a part of the orientation packet for his team. Would he ever consider publishing a "lied and died" project metric? That would be career suicide. Yet he operated every day in this exact fashion.

Screw them before they screw you

A former business partner of mine was excellent at finding weaknesses in our contracts and shoring them up. He was excellent at negotiating terms favorable to us. He was adept at ferreting out customers who might be difficult to work with. I genuinely appreciated all of these characteristics as they clearly offset my naivety. But as time went on, I found it more and more difficult to enter into engagements with clients. Our contract and terms were off-putting. Clients were confused by the incongruent presentation; a personable, amicable, partnering sales cycle followed with a iron-clad, one-sided contract. This became a point of contention between us. I was stripping contracts back to basics and working hand-shake deals while my partner was rallying for more stringent terms and insisting we kick anyone who didn't comply to the curb.

Then one afternoon, we were in a rather heated discussion over the subject and he said to me, "People are out to screw you. Everybody is out to screw us. That's how it works. You need to screw them before they screw you."

Would he have written a book entitled, "Making it in business: screw them before they screw you"? Would he put on his resume that he was entirely distrustful of people and had no issues screwing them over? I think not. But he lived his life by this very creed.

C'mon, Doc. Those are extreme cases.

I am not convinced any of them are extreme. None of them are of a character furthest removed from the ordinary or average. But let's step away from overt actions of personal disregard and distrust and look at the certainly common.

Cut corners to get it done fast
Give teams who are supposed to work together conflicting objectives
Make sure employees are 100% utilized
Use metrics as goals and reward results
Rely strictly on policy to guide behavior
Dispense information on a need to know basis
Demand solutions instead of problems
Accept accolades for success and place blame for failure
Work 60+ hours/week
Foster a culture of heroism
Don't ask for help
Speak for the customer rather than to the customer
Prioritize new features over defect fixes
Make sure everyone knows who's in charge
Tell people what they want to hear, not what you believe can be done
Make everything a top priority
Ask for all or nothing
Multi-task

I propose a different saying

Preach what you practice.

I'm not saying we all need to stand atop boxes and share our primarily banal existences with the world. That's what Facebook's for.

But I do encourage you to stop and reflect regularly; would you be willing to preach what you practice?

Leading by Example

2011-01-16T22:12:00.001-05:00

I'm nothing special. I've known this for a long time. I'm not a naturally talented programmer, if there even is such a thing. Nor am I a top programmer. This is not self-deprecation. I am not ashamed of this fact. I don't think I should be.

Where I am today as a developer is remarkably reminiscent of my days running high school cross country. I was not a natural talent at running either. I worked hard. I became a varsity runner. This put me in the top 10% of the team. I never placed first for my team in a varsity race. Not once. But I frequently placed third or fourth for the team, putting me in a scoring position. I was regionally ranked in the top 100 and we were the best region in the state, putting me somewhere in the top 250 in the state. Nationally, however, I was nowhere near the top 1000. I never ran in a state meet. I never made the local paper except when the whole team made the paper.

I was, as you might imagine, opinionated and vocal. I read about running. I put what I read into practice. I read about diet and I applied what I learned. I was by no means the fastest on the team, but I was confident that I was doing the right things to maximize my personal abilities and I wanted to share that with anyone who wanted to listen. Truth be told, I shared it with many who really didn't want to listen.

My enthusiasm paid off. My senior year, I was named co-captain of the team. I was an official leader of the team. It was a role I took very seriously.

There was another kid on the team. He was quiet. He didn't speak up much. He was supportive, helpful, kind, and fast; faster than me. Like me, he never placed first for the team, he never made it to state, and he never made the local paper as an individual. He, however, did not make team captain.

All things considered, he should have made captain. He should have been labeled the leader. He worked hard; he was supportive, kind, and helpful. He possessed all the characteristics of a leader. And he was fast; faster than me.

But he was not outspoken. He did not tell others about his latest readings or his new diet ideas. He did not try to get others to listen to him and validate his thoughts. Instead, he just did his thing. He just ran. And through his behavior he set an example for everyone else. Through his actions, not his words, he modeled what it was to be a good runner.

He didn't make team captain. Maybe because he didn't need it. Or maybe because I needed it more and tradition limited the number of captains. But he was a leader. He was absolutely a leader on that team.

I meet people like this every now and again. Someone who is so humble and unassuming, you are likely to overlook them. You are likely not to notice what it is they have to offer.

As runners, there was no doubt. You could see who was fastest. It was quite clear. But as developers, you can't always see the beauty, the grace, or the power. As developers, our ability is not so readily apparent.

I paired with such a developer today. His name is Matt Yoho. I've met him before. I've talked with him before. But today, I came to see the beauty, the grace, and the power that he brings. What I like most about this guy is that he leads by example.

Matt performs and it speaks for itself to anyone who cares to listen.

You are a Leader

2011-01-01T17:27:00.005-05:00

Leaders are chosen

Leadership is neither assigned nor selected. People choose whom to follow and a leader thereby emerges.

“The led must not be compelled, they must be able to choose their own leader” - Albert Einstein

We always have a choice. We may not like our options. We may feel we are choosing the lesser of two evils, but nevertheless, we follow at a minimum because we choose not to do otherwise.

“The man who lets a leader prescribe his course is a wreck being towed to the scrap heap.” - Ayn Rand

Leadership is by example

Example is not the main thing in influencing others, it is the only thing. - Albert Schweitzer

Words inspire others to action, but they don't make a leader. Words make an orator. Action makes a leader. One must do, must set an example, must establish a direction in order for others to choose to follow.

Positive, negative, or even neutral; the actions taken set examples for others.

A leader leads by example, whether he intends to or not. - John Quincy Adams

The quality of a leader is the quality of their decisions

Every action is the result of a decision. The quality of our decisions are not determined by the quality of the choices available, rather by the quality of our character. What we do and do not consider to be available choices is entirely about character. What we ultimately choose is a mere nuance.

The self is not something ready-made, but something in continuous formation through choice of action. - John Dewey

Through character, we make our decisions. Through each decision, we determine an action. Through each action, we create a result. Through each result, we garner a lesson. Through each lesson, we build character.

Leaders follow

All leaders are followers. All followers are potential leaders.

You cannot be a leader ... unless you know how to follow, too. - Sam Rayburn

Leaders select others from whom they take cues; others whose actions they find inspiring.

To lead, one must follow. - Lao Tzu

Leaders inspire others through action. Great leaders fall in stride beside others who are on the same path.

We are all leaders

We all make decisions. We all take action. We all set examples. We are all leaders.

We may deny our qualifications. We may retract our candidacy for leadership. But it is not up to us. Leadership is neither assigned nor selected. Leaders are chosen.

When you show up late to stand-up and fail to uphold your team agreement, you have take an action and are, in that moment, a potential leader for others to choose to follow.

When you invite a team mate to pair with you, you have taken an action and are, in that moment, a potential leader for others to choose to follow.

Strive to be a good leader

Your influence, intentional or not, is greater than you may imagine. Strive to do well. Endeavor to do right. Be cognizant of the example you set with every action.

The creation of a thousand forests is in one acorn. - Ralph Waldo Emerson

What are you rewarding?

2010-12-20T10:00:00.004-05:00

We don't pay bonuses

It is nearing the end of the year and we at LeanDog are wrapping up our fiscal year. We're looking at the potential tax benefits of spending some of our reserve and we're mulling over other ideas related to the spend of money. We are not, however, discussing our bonus objectives. We aren't discussing them because we don't have them. I, for one, am happy that we don't.

Plenty of companies have bonus objectives. Many of those companies are spending a great deal of time (and money) trying to make sure that those objectives are met (or at least appear to be met). To some, this sounds like a good idea. To me, it sounds like rampant dysfunction.

Bonus programs often fail

I recall working with a customer who was very keen on ensuring maximum utilization of their "resources". Each manager had utilization targets with associated fiscal incentives. Meet the target, get a bonus. Fail and get none. Simple enough.

But this entire system proved to be counter productive and misguided.

The metric becomes more important

Managers were spending a great deal of time monitoring the time-sheets of their employees. Managers would download the data and run it against various formulas to make sure they were within limits. If an employee's ratio was off, the manager needed to figure out how to allocate the time to get the ratios correct, discuss it with the employee, and validate the changes once they were made. In many cases, the time was tracked under the wrong category because the task that was clearly most applicable was not categorized in accord with the allocations. The time was instead allotted to some other task in order to get it into the right category. Much work was done to make sure the allocations were met. The accuracy of the system degraded over time. People's hours were no longer tracked to the actual task, but instead tracked to areas that kept the ratios favorable.

Good work is sometimes punished

Among the development teams, there was one that delivered to the delight of the customer every time. Their bug count was extremely low. Their customer was actively engaged in setting priority and was aware of the status at any given time. The team worked together, communicating, collaborating, and making things happen. They delivered more frequently with higher quality than any other team in the department. But their ratios were off. For a utilization target of 90%, they were consistently floating at 85%. They were tracking their time honestly. Their manager refused to doctor the time while all other managers were complicit in time doctoring. Directors were given incentives for the percentage across all their teams. So unless the other teams fudged enough to beat the target by a few percent, the director wasn't going to make the bonus mark.

Ultimately, the manager who delivered and was honest failed to meet the bonus objective and was both paid less and reprimanded for failure to meet the company standard. Other teams failed to deliver anything in a year, but showed the proper allocations and were given a bonus.

A raise is a bonus that lasts forever

My advice to managers, directors, and executives who want to pay bonuses? Don't. If you must do so, then break it down based on each employee's income. If you have a top performer, don't give them a bigger bonus, give them a raise. Think of a raise as a bonus that lasts forever.

Lost in Translation - An Agile Game

2010-12-08T14:17:00.000-05:00

Timing:
One hour, but this can be extended or contracted as needed.

Materials:
Pencils, paper, timer, and a collection of pictures (royalty free).

Instructions:
One person is the facilitator. The facilitator keeps time, makes sure the rules are being followed, and facilitates the retrospectives.

The rest of the people are broken up into teams of three; a product owner, an analyst, and a developer. The product owner is provided a picture chosen at random from a collection.

The product owner is not allowed to show the picture to anyone else.

The team needs to create a hand-drawn depiction of the picture.

Round One:
Requirements (10 minutes)

The developer leaves the room.
The product owner describes the picture to the analyst.
The analyst captures the requirements.
The analyst may ask as many questions as needed in the time allowed.

Delivery (10 minutes)

The developer returns and the product owner leaves.
The product owner needs to remain nearby for questions, but not in the room
The analyst provides the written specification to the developer.
The analyst may provide answers to any of the developer's questions.
The analyst may ask the product owner as many questions as necessary, but must leave the room to do so.
The developer draws the picture.

Retrospective (10 minutes)
What went well? What did not go well? What would have made it better?

Round Two:
The product owner is provided another random picture.

Delivery (15 minutes)

Everyone stays in the room.
The analyst and developer work together to create the picture.
The analyst and developer may ask the product owner as many questions as necessary.

Retrospective (15 minutes)
What went well this time? What did not go well? What would have made this better?

How does round one compare with round two?

Learning Points:

Working face to face is easier and more rewarding
Working together in real time produces a better product
Documentation is less valuable than communication
Roles are not so important when it comes to getting the work done

The Three "R"s of Clean Code

2010-12-02T11:40:00.000-05:00

Establishing Code Quality Standards

Mandate via Manual

A client of LeanDog was looking for a way to introduce code quality standards to their development teams. There had been a few meetings prior to LeanDog's involvement. The prevalent line of thinking was to draft a standards manual for dissemination to the teams. This would consist of a comprehensive set of rules and clear specifications to which all teams need comply.

There was a good deal of discussion around people's historic failure to read and follow this type of documentation. Such failure to comply mandated policing. There were a number of possible solutions; training, financial incentives, managerial targets, code reviews, code audits, and code compliance tools.

Ummm, yeah. Don't do that. Ok?

Keep it as simple as possible. Assume the people you work with are competent, capable, and want to do their jobs well. Developers tend to take personal pride in their work, as do most people. I've yet to meet anyone in the field who proudly (and seriously) proclaims, "I do my job poorly."

This kind of governance should not be necessary. If it is necessary, then remember that your people are competent, capable, and want to do their jobs well. Failure to meet a standard says more about the standard than the people.

It is likely the problem is the manner of communication and enforcement.

Voice via Vignette

Rather than a tome of requirements or a blanket statement such as, "Follow the standards in Clean Code.", give the team simple guidelines that they can agree to and internalize. Short, simple reminders of what quality is to the team. With these simple reminders, they have a catalyst that fires the synapse that brings back all the other "rules".

Enter the Three "R"s of Clean Code

For this particular client, LeanDog helped to establish a set of three simple reminders; Readable, Reliable, and Responsible. These may not be the right reminders for your team. Work together to find what resonates with you.

We restricted ourselves to a single sheet of 8.5"x11" paper and documented the standards we felt were most important. Once the page was filled, we reduced it by eliminating duplicates and highly similar items. We then sorted it in priority order and cut it to half of a page. We then studied the list and came up with groupings. We moved items into the groups and discussed how it all "felt". It took only a couple of iterations to finalize the list.

The team now has four signs that hang in their work space. The three Rs and The Boy Scout Rule Each of the R signs has a short list that further describes what the team means by the "rule".

Readable

Descriptive Function Names
Small Functions
Few Comments
Few Arguments

Reliable

Tested
Descriptive Function Names
Necessary Code

Responsible

Single Responsibility Principle
Necessary Code
Tested

Less is More

We did not cover many things. We don't talk about specific conventions for naming. We don't cover formatting items such as indentation or where the curly-brackets belong. We focused on a select few things that the team felt would guide them toward better overall code. These signs hang up around the work space as regular, simple reminders. And the entire team not only knows what these mean, they follow them without any governance beyond integrity and a commitment to the team.

What would be on your list?

As I said, the list was developed by the team for the team. Maybe there is something you think is very important that was overlooked. Think on this for a while and then let us know what your personal (or team) list would look like.

LeanDog Extreme Meeting

2010-11-29T09:46:00.012-05:00

What is an Extreme Meeting?

Stairs made it "easier"

I definitely have to give the nod to Jon Stahl on this one. I'm not sure where he got the idea. I've not asked. But it wouldn't surprise me if he came up with it all on his own. If you know Jon, you know what many of us would consider extreme is pretty commonplace for him. If you get the opportunity to sit down with him and you don't want to talk about agile or lean, be sure to ask him about his trip to the far north. It is an epic story.

The basic premise is simple; get out and do something that tests your stamina, creates a sense of team, and allows you to have discussions you might not otherwise have.

So far, I have to say I am a fan. I liked the concept, but was apprehensive of the potential outcome. My primary concern was if everyone could make a 14 mile challenging hike. We placed a vehicle at the turn-around point, which helped. We also chose a route that started easy, got more difficult, and then ended very flat and easy. Warm up, work hard, cool down.

Format

Pre-Event

Status Update

We preselected a few important strategic topics. Individuals were assigned responsibility for the items. To be quite specific, we ran an A3 process several days prior to the hike. But the A3 piece is not necessary, only a select set of key topics and an "owner" for each topic.

Iterations

We were headed out for a 14 mile hike, so we broke the hike up into sections approximately three miles each. The team met at the trail head and each topic owner gave a brief overview of their item. We then split up into small groups, each focused on a specific topic.

Jon Selects a Lunch Spot

We hiked a leg of the trail, talking over our thoughts and ideas on the specific topic. The topic owner facilitated the session, making sure we stayed near enough to the original topic, without entirely dominating and controlling the discussion.

At the end of each leg, we briefly discussed the experience as a larger group. We then split up into new groups. We decided at each point if we wanted to retire a topic and introduce a new one or continue with a prior topic. It was all quite dynamic and the general lack of formal agenda allowed us to organize around things as we thought necessary.

Retrospective

Discussing Strategy

At the end of the hike, we met at The Winking Lizard in Peninsula, OH. The Lizard is a wings and beer pub that has been around for many years. It was a nice venue to wind-down, have a drink, and get something to eat.

We generally agreed to try mini-presentations at each break. This would allow each of us to get a quick (3-minute) update on each of the topics.

Next Event

We are thinking about an over-night canoe trip for the next one. Clearly, this will have to wait until the weather is more appropriate. Other suggestions were sky diving, rappelling, and white water rafting. They all sound fun (or at least extreme), but it is important that the activity provide for discussion first and foremost. I, for one, would have a hard time holding a conversation while simultaneously fighting to hold down my lunch.

One week of this positivember crap

2010-11-07T02:53:00.001-05:00

You know, this wasn't as easy as I thought it would be - this whole being positive thing. I made it really hard on myself at first. If I faltered, if I had a negative thought or got frustrated, I got down on myself for not doing better. After about 36 hours of that, I realized that getting down on myself was certainly not in the spirit of positivember. I realized that it was not a lack of negativity that I needed to focus on, rather an increase in positivity. Not happy fluffy bunny stuff with cotton candy and unicorns and rainbows. Although unicorns are cool. But just looking for the good in others, the positive of the moment, or how I could do something to make the day of another a little better.

So I decided to allow myself to get down or grumpy or frustrated, but only for a moment. And rather than admonish myself for having done so, I'd make an effort to counter the negativity and then surpass it. After about 36 hours of that, I realized I wasn't feeling negative nearly as often. I was actually feeling pretty positive.

I also decided to learn something new every day in November. It doesn't have to be huge, but I do have to make an active effort to achieve it. If I happen to pick something up along the way (which I often do), that doesn't count. And in the last week, I've learned a bit more about vim, I've taken another look at closures in javascript, and I've worked my way deeper into the clojure koans.

I know it is only day seven, but November is shaping up nicely.

Honestly, I see no reason to limit myself to just one month. Maybe I'll try to keep the streak going until the end of the year.

Keep your ears, your eyes, and your mind open

2010-11-02T10:09:00.000-04:00

Developers shouldn't specialize

Davey Brion wrote a post not too long ago warning developers about the dangers of specializing in a particular technology.

The real message

Davey concludes his post with the following paragraph:

"Keep your ears, your eyes and your mind open. If you notice that a group of people gets excited about something new, then figure out why. If you notice that something appears to be working well for others, then figure out why. If you notice an increasing stream of criticism on the technology you’re using, then figure out why. You’ll need information like this to make well-founded decisions about your future."

If you are a practitioner of Lean, you are likely to find yourself trying to convince others that they should focus on one item at a time and observe the flow of work. If you are a practitioner of Scrum, you are likely to find yourself trying to convince others that they need to commit to an amount of work each iteration and observe the burn down. And if you are a practitioner of XP, you are likely to find yourself trying to convince others they need to use TDD, pair programming, and other engineering practices.

There are good ideas in each of these approaches. There are a few conflicting ideas, certainly. But there is a lot more in common than there is different. And there are valuable ideas from each that fill gaping holes in the others.

When you focus on a single approach, you not only constrict your ability to grow and learn, but worse, you cultivate a bias. When the information you receive is accepted or rejected based on how consistent it is with your current thinking, you limit your ability to make new distinctions.

I encourage you to follow Davey's advice. Pay attention to the buzz around new ideas. Rather than figure out how to tear it down and dismiss it, find what it offers that is of value. If you hear of others achieving success with other approaches, investigate and seek new ideas you can adopt. Pay attention to the frequent criticisms of your own ideas. Rather than immediately trying to defend your ideas, give legitimate consideration to why this counter-perception exists and if there is anything you can learn from it.

Should we always pay back Technical Debt?

2010-10-31T09:11:00.001-04:00

Jim Highsmith on Technical Debt

A former coworker of mine, Jim Highsmith, has recently written an article on The Financial Implications of Technical Debt. Jim states that recent studies indicate the cost of technical debt is near $1 trillion in the U.S. I would like to see these studies. I do know that not too long ago, Gartner released a report indicating that the worldwide cost of IT Debt will be $1 trillion by 2015. Regardless, the point he makes is still valid - technical debt is egregious.

Jim states, "Unfortunately, by the time many organizations are paying attention, all the solutions are bad ones: 1) do nothing and it gets worse, 2) re-place/re-write the software (expensive, high risk, doesn’t address the root cause problem), or 3) systematically invest in incremental improvement."

Of these three (bad) options, I think the second is often a better choice than the third. The first represents failure to make a necessary decision.

Just chuck it

Let's assume a product has been in development for a few years. During that history, the software delivery team has garnered a significant amount of domain knowledge through trial and error. Some assumptions were validated, others definitively proven incorrect. Adjustments have been made, entire screens have been overhauled to improve the user experience. The data model has been tweaked to accomodate unanticipated requirements without invalidating all prior collected data. And, as we've established, there is significant technical debt.

In this same amount of time, the development tools have undergone three major revision updates, the database platform has undergone one major revision update, and the standards for the web-based front-end have undergone significant change, not to mention the advantages of jQuery, which your app is using sparsly.

The cost of maintenance and new development is on a steep incline. Making reparations as we go along will result in a slow recovery. If it took us four years to get here, it will likely take us four years to recover; perhaps longer. If you've ever worked for a couple of days on a piece of code and lost it, you know it takes about half a day to write the whole thing again and do it better.

So what is more risky? Continuing to work on this code base, cobbling together mis-matched parts in old technologies and slowly grinding out improvements or writing a new one?

I agree good code is an asset. But, just as in other investments, sometimes the best move is to take the loss and get out rather than holding on in hopes of a recovery.

Then do it better

We've the opportunity to advance the tools and technologies. We've an opportunity to build it again fortified with several years of learning through trial and error. Take advantage of this opportunity and do it well.

Training Software Professionals

2010-10-28T23:43:00.001-04:00

The Slides

Here is the slide deck to my SCNA talk, "Training Software Professionals, Just What the Doctor Ordered". In the past, my slide decks stood on their own. That is, you could thumb through the deck and easily glean all the key points of the talk. But I am trying to move away from that presentation style to one where the slides offer visual support, but the speaker (me) tells the actual story.

Training Software Professionals - Just What the Doctor Ordered

View more presentations from Michael Norton.

The Story

I am a Software Craftsman

From the moment the phrase was uttered, people starting formulating opinions about what it means. From guilds, exclusionists, and elitism to irresponsibly meticulous artsy-fartsy types to passionate life-long learners.

For me, Software Craftsmanship is trying to live my life in accord with the values. I am not claiming that I live my life entirely in accord with the values. I am saying that I endeavor to do so. Every day. Some days, I do better than others.

We Need To Talk

We need to talk amongst ourselves and with others. We need to talk about what we're doing to actively improve the quality of software. Or more accurately, what we're actively doing to improve the quality of software practitioners, through whom, software is developed and delivered. I don't believe I have the answers. I'm not even certain I have all the right questions. But I am certain that we, as a community, have everything we need to effectively address the issue of quality in our profession.

$1 Trillion by 2015

On September 10, 2010, Gartner Group published a comprehensive study of IT Debt worldwide. The debt is estimated at $500 billion at the end of 2010 with a projection to hit $1 trillion by 2015. Many discussions on software quality meander their way into a debate about the lack of need for rigor when lives are not at stake. Given worldwide IT Debt at $1 trillion, even if only 10 percent of it is from code, we are looking at $100 billion due to poor coding practices. This is somewhere in the range of $14 for each living human. This is more than a complete year's salary for every developer on earth. While we may not be able to draw a straight line from this debt to the loss of human lives, I've no doubt the connection exists.

Our profession is failing to deliver. We must do something.

How do we improve the quality of our code? I suggest we start by improving the quality of our practitioners.

What are others doing?

Many professions have been around for far longer than ours; hundreds of years, even thousands. We may be able to accelerate our learning by observing those who've gone before us. Among the professions actively dealing with the quality of their practitioners, is medicine. This is not to suggest the medical field has yet mastered their shortcomings, but we can still benefit from their progress.

Educating Medical Practitioners

Today's physicians are educated both at school and long after graduation. They begin with a general education followed by a more specific focus on medical science. While this provides them with the science, theory, and philosophy of medicine, it does little to teach them how to apply this learning to the care of people. School is followed by a period of internship or residency where budding physicians learn how to apply their knowledge to the art of caring for people. Physicians are licensed to practice medicine and certified in areas of specialty. They engage in lifelong learning both collaboratively and intentionally on the job as well as through formal (and sometimes informal) continuing education.

General / Specialized Medicine
Internship / Residency
Licensing / Certification
Collaborative Learning
Continuing Education

Software Development in Contrast

Comparatively, the standard educational process for software developers is a general education with a few classes covering multiple aspects of general technology and perhaps some classes focused on a language or development practices. No residency. Certifications with questionable value. No licensing. Informal self-directed collaborative learning. And no continuing education requirement.

A quick history of Western Medicine

To appreciate where the medical profession is today, it helps to take a look at the events that shaped their profession. This is not a comprehensive review. The medical profession has been around for over 5000 years. In 3000 BC, the egyptians had hospitals, nursing homes, and even medical insurance. Our focus is on Western Medicine with an emphasis on events influencing the course of medical education.

Hippocrates - 400 BC

Hippocrates is often referred to as the Father of Western Medicine. He made many significant contributions to the medical field. Much of what is done today can be traced to the findings and teachings of Hippocrates.

Perhaps most significant of Hippocrates' contributions was the separation of faith and medicine. Prior to Hippocrates, most of what ailed humans was considered to be attributable to deity. But Hippocrates thinking allowed him to look more locally for the source of what ails us.

Hippocrates taught in a Master/Apprentice fashion. He housed a few students and taught them in exchange for which they helped to tend to his land and stock. Students were provided the opportunity to learn, experiment, and eventually practice as he felt they were ready and capable. Students moved on to be practicing physicians and several eventually took on apprentices of their own. Significant priority was given to the proper clinical care and treatment of patients.

The Master/Apprentice format was the prevailing form of education for centuries to follow.

Canon of Medicine - 1025

The Canon of Medicine is a vast collection of medical knowledge from both Eastern and Western cultures spanning several millennia of learning. It was considered, at the time of its writing, to be comprehensive and complete. The canon ushered in a new style of medical learning. With a single text to teach from, Masters could significantly expand their audience and share with hundreds of students at one time rather than a mere few.

Schola Medica Salernitana

Considered the Birth Place of Modern Medical Education, this medical school in Solerno Italy set the example for the next several centuries. Physicians moved away from the Master/Apprentice model to a more scalable and rapid form of education taught in lecture format based on the Canon and supporting texts.

It was generally believed that the texts contained everything possible to know in terms of medical care.

Black Death - 1350

The bubonic plague was devastating. Nearly half of England was killed and over one third of all Europe died. Nothing known about the human body, medicine, surgery, or the cause of illness helped.

Schools focused on finding new ways of identifying and treating human ailments. For the next several hundred years, the medical industry focused intently on scientific discovery and learning.

But as physicians became significantly better at treating disease, they became far less capable at treating their patients. Science had become such a focus, that proper clinical care and treatment of patients was no longer a significant part of the educational process.

Osler and Flexner

In 1904, Sir William Osler wrote a paper urging medical schools to introduce residency as a part of the curriculum. Osler regularly had students accompany him on rounds in the hospital where they learned how to treat people in a clinical setting. He wished to return humanity to the practice of medicine.

Around the same time, the Flexner report was published. The report has a great deal of controversy surrounding it. The funding and execution were questionable, but the impact was significant. The report rated medical schools in the North Americas, identifying those meeting and those failing to meet a set of standards devised by the benefactor of the report. As a result, more than half of the medical schools in the US were closed or lost significant funding.

The remaining medical schools were incapable of meeting the demand while simultaneously implementing residency programs. It was not until the 1960s that residency was common practice for all medical students. As late as the 1980s, some medical licensing still did not have a residency requirement.

Today

As mentioned at the onset, the medical industry now embraces life-long learning with a balanced focus on clinical and non-clinical learning.

General / Specialized Medicine
Internship / Residency
Licensing / Certification
Collaborative Learning
Continuing Education

Lessons and What Next

Lessons

Scholastic education is merely the beginning. Knowledge is far more valuable when we know how to apply it. Licensing and Certification can have a positive impact on the level of professionalism. Practitioners share knowledge amongst themselves and create opportunities to learn together. Professionals engage in intentional life-long learning.

What Next

As I said at the onset, I don't believe I have the answers. I'm not even certain I have all the right questions. But I am certain that we, as a community, have everything we need to effectively address the issue of quality in our profession.

We Need To Talk

We need to talk amongst ourselves and with others. We need to talk about what we're doing to actively improve the quality of software. Or more accurately, what we're actively doing to improve the quality of software practitioners, through whom, software is developed and delivered.

But talk should not take too long. Rhetoric may convince many, but will achieve little.

We Need to Act.

Do something. Learn from it. Adjust.

References

The History of medical education: an international symposium …, Volume 673 By Charles Donald O’Malley, University of California, Los Angeles. Dept. of Medical History
Medicine
Medical School
Schola Medica Salernitana
Medical Education in the United States
History Medical Education
History of Medicine
Hippocrates
A short history of medical education in the United States
The Canon of Medicine
American Medical Education 100 Years after the Flexner Report
The acquisition of skills for practice requires radical transformation. Although the dictum “see one, do one, teach one” may have characterized the way in which clinical skills were learned in the past, it is now clear that for training in skills to be effective, learners at all levels must have the opportunity to compare their performance with a standard and to practice until an acceptable level of proficiency is attained.
- The New England Journal of Medicine, September 28, 2006
Internship
Residency
William Osler

Uncle Bob on Humility

2010-10-25T15:09:00.003-04:00

The following just hit my inbox. It is a post on the Software Craftsmanship Google Group.

On Oct 24, 2010, at 12:36 , David Starr wrote:

My question is, "what can be done to fix the reputation [of elitism] and change the conversation before craftsmanship is deemed irrelevant"?

As a craftsman I am dedicated to improving myself; and therefore I realize I am deficient. As someone who is admittedly deficient, I am not interested in pointing out someone else's deficiencies.

In general, whenever someone asks "what can we, as a group, do to ...", the best answer is going to be of the form: "Each of us, as an individual, should ...".

So, to deal with perceived elitism, each of us as individuals should remember that we are not elite.

----

Robert C. Martin (Uncle Bob) | email: uncle*@objectmentor.com

Object Mentor Inc. | blog: blog.objectmentor.com

| web: www.objectmentor.com

| twitter: unclebobmartin

Packing Peanuts Game - Variation

2010-10-24T21:29:00.000-04:00

Searching for a Game

I was looking for a game that helped to emphasize the detrimental results of a focus on speed over quality. How such an approach had only a short-term gain and then proved to be more costly from there forth.

The Original Game

I don't know if this is really the original version of the Packing Peanuts Game, but it is certainly the first I've found.

The game was posted to tastycupcakes by Masa K Maeda, on May 21st, 2010

Masa identified the game as a way of "understanding what Technical Debt is and why it is so costly to projects." You already know my feelings on calling sloppy code Technical Debt, so I won't go into that here. But it is a decent game for showing that haste does in fact make waste and the only way to truly go fast is to go well.

Timing:

10 minutes

Ingredients:

4 cardboard boxes. Size: around the standard size of a moving box (13”x18”x12”)
Enough packing peanuts to fill two of the boxes
2 people

You can do this exercise with more people, adding 2 at a time, up to 6 people without the need to have more boxes or packing peanuts
For more than 6 people you’ll need to add more boxes and packing peanuts

Setup:

Set 2 lanes across the room
For each lane place one cardboard box (opened for easy access) at each end of the lane.
Fill the boxes at the same end of the lanes with packing peanuts: one of them at 70% capacity, and the other one at 90% capacity
Each participant will stand next to a box with packing peanuts

Execute:

Explain the participants their goal: To transfer all the peanuts from the box next to them to the box at the other end of their respective lanes.

The person with the 70%-full box is to transfer all of them in three trips and can use hands and arms (and support them on his/her belly if so desired), but nothing else
The person with the 90%-full box can take as many trips as desired and can use both hands only
The boxes are not to be lifted, tilted, shifted or other. Their sole purpose is to contain the peanuts
Peanuts that fall on the floor are left there
There is no time limit
Do not run and watch your step
Start the game
Let them play for about 2 minutes or until one of them accomplishes the task

Expected Results:

The person with the 90%-full box will finish first or will have transferred more peanuts once the time is up
The person with the 70%-full box typically drops way more peanuts to the floor
The person with the 70%-full box exerts and stresses more

Learning Points:

The peanuts represent features or aspects of features, and those on the floor represent unfinished work, bugs, etc.

One trip represents a release cycle: more peanuts per trip represent a bigger release
Big monolithic projects generate more technical debt
Big monolithic projects take more energy out of people, and stress them more
Trying to bring all features from start to end at once is way more difficult
Bringing features to completion in small chunks is easier, and generates less technical debt (less peanuts on the floor)
Bringing features to completion in small chunks allows people to work at a better pace and under less stress
Bringing features to completion in small chunks results in more features done in less time

Variation

This variation of the game is designed to further accentuate the cost of allowing cruft to build up in the code base.

Clearly mark the lanes at 24 inches wide.
Teams must travel within their lanes.
When the game starts, the source box has peanuts and the destination box does not.
Fill both source boxes to 90%.
Team A is limited to four trips, but can use arms, chest, and stomach to hold as many peanuts as possible.

No pouching of clothes or putting peanuts in pockets or up/down clothing.

Team B can use as many trips as desired, but can use only hands.
When returning to the source box, Team B must collect any previously dropped peanuts and return them to the source box.
Team A does not need to pick up dropped peanuts unless they step on them
Team A must immediately collect any peanuts they step on
Moderators monitor Teams' peanuts and lanes

Any peanuts dropped outside of a lane are immediately swept into the lane.

Play until either Team A is out of moves or Team B transfers all peanuts, whichever is first.

The idea here is to model what happens in many companies. The team is permitted and even encouraged to go fast and sloppy for some period of time. But the mess eventually impedes the team's ability to move forward at all.

Code as a Cause of Project Failure

2010-10-19T08:43:00.003-04:00

The original question

During the speaker panel at SCNA this past weekend, Chad Fowler (@chadfowler) asked, "How many projects fail because of the code?". Given the context, I assumed he was making the point that projects fail due to business issues, not code. The room was silent. While one might have assumed this meant the entire group thought it rhetorical, I concluded everyone agreed with Chad. Projects fail not due to code, but due to business issues.

The follow-up

Uncle Bob (@unclebobmartin) later did a quick twitter survey, which I and many others took part in. The results were overwhelmingly in favor of project failure being more attributable to business issues than technical issues. Bob felt many might take this to mean that code is not all that important in the long run and that craftsmanship, therefor, is not all that important either. Bob put together a well thought-out argument explaining why code is important and how it can, in fact, kill not only a project, but entire companies. Rather than reiterate it here, I strongly encourage you to read Bob's article, "The Cost of Code?" I agree with most of what Bob says in this article. The Cost of Code is high. I don't agree that all failed projects are due to code, but his points in support of that statement are no less valid.

Cause versus Responsibility

Smoking Guns

A man lays dead; a single bullet wound in his chest. A project fails; a mass of crappy code remains. Perhaps it is clear to you that a bullet killed the man. Perhaps it is clear to you that crappy code killed the project. Rather than enumerating other possible conclusions, given our substantial lack of evidence, I will conceded both points. The man was killed by a single bullet and the project was killed by crappy code.

Yes, technically, the project failed due to code.

Trigger Men

Our tragedies do not end there. We can no more stop murder by eliminating bullets than we can save projects by eliminating the need for code. While the bullet or the code may be the cause, they are both effects as well.

Somebody pulled the trigger.

In large projects, identifying one guilty party is commonly impossible not to mention grossly naive. In large projects, there are typically many humans responsible for the failure. If we were to perform archeological studies on the ruins of most projects, I am confident we'd find the failure to be between people. I am confident we would find it was a failure of communication. Not one, but hundreds or even thousands of failures; large and small. Lack of vision. Lack of clarity. Lack of cohesion due to lack of vision and clarity. Lack of clear expectations. Unclear status. Keeping quiet when we disagree. Raising disagreements in a non-constructive manner. Approaching debate as if it were battle. Inflammatory language that creates divides. Hiding our mistakes. Sending an email instead of making a phone call. Making a phone call instead of meeting face to face. Too much emphasis on delivery. Thinking speed and quality are diametrically opposed. Undervaluing the work of others. Apathy. The list goes on.

On a software project, code is critical. You can't have a software project without code. The worse the code, the greater the risk to the project. Bad enough and the project will fail as a result of the code. Significant enough, and the company will fail as a result of the project.

But don't forget it is we who write the code.

It is we who pull the trigger.

On The Scrum Compliance

2010-10-18T14:46:00.000-04:00

A recent article by Tobias Mayer has been getting a lot of attention. "The Scrum Compliance" is an accounting of why Tobias is moving on from the Scrum Alliance. This article is not the first on the ugliness that has become the Scrum Alliance.

I've read this article a number of times and I am disheartened by all of this. Such an ugly series of events playing out in an opaque manner on a semi-public stage. We hear pieces of what has transpired and assumptions about what motivates the participants. We get facts mixed with opinion mixed with emotion. The "logical" conclusions, when seriously considered are not logical. That the committee representing the Scrum Alliance is comprised of power-greedy oligarchs does not at all seem like a logical conclusion. Yet, I hear it stated as if it is known fact based on the "evidence".

I'm neither defending nor attacking anyone here. I think Tobias is an honorable man who speaks from the heart. I am not saying that he is right or that he is wrong. I am saying I do not know, that very few of us actually does, and that he alone cannot tell the entire story.

Regardless, I now question my connections with the Scrum Alliance. They are not particularly tight, but whether I believe the rumors or not, it seems a good time to be a distance from the SA rather than standing next to it, taking shrapnel.

Esther Derby asks: Are we aiming too low?

2010-10-10T18:37:00.001-04:00

Esther Derby's Post

Esther Derby put together a nice post on the importance of design for a web site in which she asks, "Are we aiming too low?"

Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?

Makes me wonder

Story Composition

I've been working with teams lately on story composition. We've been discussing how we could break stories down based on value to the business rather than based on how we technically execute. Our objective is to be able to deliver value to the business as quickly as possible. So we want to avoid chunking larger stories out into smaller stories that are then dependent upon one another for delivery. We've really achieved nothing other than creating bottlenecks in our flow. We still have to build the whole thing in order to deliver.

So a common technique we've been using is to break out aspects of the story that are must have from nice to have. Often, this ends up being along the seam between functional and sexy. With functional clearly being must and sexy riding shotgun at best.

Executing on this strategy, we are able to deliver functionality faster and we haven't any dependencies between the stories other than the must have need to come first. But this is perfectly acceptable to the team. Must have should come first.

Are we missing something important?

I think we are. I think by consistently breaking the stories down in this manner, we are cheating the customer. We keep putting features that make the application nice to use on the back burner. Frequently they don't get implemented because the next "must haves" bubble to the top of the queue as the "nice to haves" slowly drop.

But by executing in this manner, we are consistently missing the opportunity to make the user experience truly pleasurable. We are focusing too much on utility and not enough on what makes the application truly desirable.

Technical Debt versus Cruft

2010-10-06T17:15:00.002-04:00

Am I Tilting at Windmills?

I repeatedly find myself in discussions with really smart and experienced people regarding Technical Debt. And I consistently find myself ranting about how cruft and technical debt are not the same thing. I am beginning to feel I am merely tilting at windmills.

I don't know if my prior rants on the topic of Technical Debt have provided sufficient clarity. In them, I try to better define Technical Debt and point out the differences between it and cruft. But I do not provide any tangible examples. Herein, I attempt to remedy that situation. Today's installment is in narrative form. I intend to provide a later post with code examples.

Technical Debt - A brief reprise

Ward Cunningham coined the phrase Technical Debt

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise."

As he clarifies later in a You-Tube video, Ward was specifically talking about design decisions made in the course of developing software that allowed for more rapid delivery. Rapid delivery not for the sake of meeting a deadline. Rapid delivery to illicit quick feedback, thereby providing the data necessary to adjust the design to be more congruent with actual needs. The object design should change to reflect your current understanding of the domain, even if that understanding is partial. Technical debt is payed back through code refactoring as our understanding of the domain matures.

Ward clearly states, "The ability to pay back debt [...] depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem."

Clean Code is actually a prerequisite for Technical Debt. If you don't have Clean Code, you cannot expect to pay the debt back. If you have cruft, you cannot reasonably incur Technical Debt. In fact, you are not incurring debt, you are merely adding to the existing mess.

Examples (in Narrative Form)

Technical Debt

Example One

We are building a new application to allow our customer to sell widgets and parts to distributors.

Widgets represent 75% of the sales.
82% of the customers order on terms.
The cross-section of these two groups represents 69% of all sales.

In order to get the application running and generating revenue, we decide to launch with only widgets and terms. We will sell parts later. We will also add other forms of payment later.

This is a strategic decision. We are creating a design that we know will have to change. We know we will re-visit this code and perhaps even throw away some (or much) of it.

But we write it well, we test drive it, and we do not compromise quality. We will defer to the last responsible moment and make the design adjustments based on what the business determines is the next highest value activity when it is decided.

Example Two

We are working with a third party API for determination of flood plane coverage for a given property. We want to know this so we can decide if we will or will not provide an applicant a loan. We don't give loans on properties in flood planes.

We can make numerous calls to the service. One, which is simple, will tell us if the property is in a flood plane or not. This is all we need to know for an accept or reject call.

We decide to go ahead with this basic functionality and make sure the service is consistently reliable in terms of uptime, speed, and accuracy. We are going to run one server against the new service and leave the others running against the old (slow and more expensive) service.

Once we've determined the service provider is reliable, we will also code the pieces for garnering more specific data. It would be good to have this on the loan application record if there are any questions in the future, but it is not mandatory.

This is a strategic decision. We are creating a design that we know will be either eliminated or expanded.

We write all of the code well. We test drive it. After a period of learning, we will either toss the code or we will add new features.

Cruft

We are working on a system to schedule production of widgets on the factory floor.

We have a bonus initiative to get the application done by the end of the year. It is September and we're just getting started due to delays in the delivery of our prior project. According to the schedule, we should have started in May. If we miss the deadline, there will be much gnashing of teeth. If we miss the deadline, we will not get our bonus. We ask our boss if we can deliver only part of the application, but her bonus is much more significant and requires complete delivery. She denies the request, admonishes us for putting her in this situation, and reiterates the priority of this project for "the business". She let's us know that the CEO is watching this one. The CEO was watching the last project too. That's how important IT is to the corporate strategy.

So we work like crazy. We skip unit testing. We work in silos and make decisions on the fly about ambiguous requirements. We notice the FillQueue class is getting quite large and everything is dependent on it. But we don't have time to change it. It works and we are under pressure to deliver. Besides, we could no longer test these classes in isolation if we wanted to. We'd have to tease them apart at the seams and that could take weeks. It is getting more and more difficult to write the code. It is like a bowl of gelatin; you touch it down here and it wiggles up there? Why does it do that? Whatever. We need to make the deadline.

This is the wrong decision for the business. This is not a strategic initiative. This is not professional or even ethical behavior. This is a failure.

But bonuses got paid.

What about you?

I've been told delivery teams don't take on Technical Debt as a strategic initiative, rather most produce cruft and then call it Technical Debt. Help me prove otherwise. Please post a comment with an example of Technical Debt (not Cruft) taken on by a team you worked on.

Values Revisited

2010-10-04T10:53:00.002-04:00

Then

In 1992, I started a custom software development company out of my basement. I started it because I was angry. At a relatively young age, I was already keenly aware of the gross dysfunction that existed in most organizations. I didn't want to be a part of that. I wanted to be a part of something different; something better. I had no plan, but I had an abundance of temerity.

Our progression over the years was adventurous, romantic, and stupid. Moving into our first real office. Housing my partner in my basement. Running out of gas on the way back from a critical meeting because we didn't have enough cash to fill the tank. The victories. The losses. The camaraderie. The angst among us.

By 1997, we were close to 20 people. Tiny, yes, but I felt it was too big for me to handle at the time. I was 29 years old with no formal education and limited "real-world" experience. My penchant for self doubt was getting the better of me; temerity had been replaced by timidity.

In a moment of melancholy and introspection, I sat down and drafted the following. It was my intention to express a core set of values to the employees of my fledgling company. And I do suppose it served that purpose. But it was the first time I had committed to paper the things I was looking for in a company. Perhaps the things I was looking for in life.

Our Values...

... are the foundation for all decisions. They serve as the compass that guides us through our personal and professional lives. All action; all thought; in every way we represent ourselves; we must represent our values.

Be fair.

Find the answer that best serves all parties. Act upon your highest sense of right.

Improve.

Grow continuously, personally and professionally, in small ways. Evolution is the sum of many tiny, nearly indiscernible adjustments.

Innovate.

Seek new ways; seek new means; do the unexpected.

Take Initiative.

Present your ideas. Put forth the extra effort. The one who makes the most mistakes, learns the most lessons.

Be accountable.

Answer for your mistakes and your deserved praise will come.

Be forgiving.

Seek to understand and assist. Do not condemn others for their differences. To criticize and dismiss leaves neither party better off.

Participate.

Become truly involved. Make this your team, for it already is.

Have respect.

Honor your coworkers and clients.

Live.

Make your life rich in many ways. Seek new experiences, new relationships, and a new perspective. Then bring it back and teach others.

And always, Tell The Truth.

- Michael J. Norton (1997)

Since

In 2001, we closed the company. The values statement had been posted on my wall for several years. It had become invisible. Sitting in the same place year after year, it was no different than the pencil holder on my desk. I could look in the general direction and not consciously recognize it was there. Only when I specifically sought it out did I truly see it. And I had stopped seeking it out.

By the time we officially closed the company, I had returned to corporate America, seeking knowledge, wealth, and (most of all) security. As I noted, temerity had long since given way to timidity.

For several years, I climbed the ladder making my way to CTO. I kept the values statement in my day planner. But it was still invisible. I did not seek it out. And when I stumbled upon it, I glanced and moved on. I felt that most around me were living by a different set of values and that perhaps I was too naive and idealistic.

In 2009, I was let go. I should have resigned of my own will, but I was too much a coward, so they provided me the opportunity.

I was feeling melancholy and introspective and for the first time in nearly a decade, I looked at my values statement again. I mean really looked at it.

And I changed my life.

Now

I am a partner in a firm that is consistent with my values. I do work that allows me to share these values with others in indirect ways. I surround myself with people who represent who and what I wish to be.

And I make sure that I take the statement out every so often and look at it. I mean really look at it. Melancholy not required.

A blank wall and a fist full of index cards

2010-09-30T16:40:00.000-04:00

I'm occasionally asked, "Doc, we're looking at product X, Y, and Z, but we just can't decide which is the best one for our project. What do you recommend?"

I've used VersionOne, Rally, Mingle, Pivotal Tracker, Kanbanery, ScrumWorks, and a couple of others including Excel spreadsheets.

For the most part, the tool gets in the way. And people getting started in agile frequently confuse what the tool is capable of (or appears to be capable of) for agile "best practices". If the tool doesn't allow you to add lanes or queues, then you shouldn't be using them. If the tool says to estimate everything in points using Fibonacci, then you shouldn't use t-shirt sizes. If the tool provides reports on personal velocity, then you must need to know personal velocity.

I think you get the point.

I like to start teams off with a simple card wall. Maybe it is a kanban board. Maybe it is a scrum board. Whatever it is, we design it together in a single session where we make broad-stroke decisions about our process.

We retrospect frequently (regularly) and evaluate if the board is working for us or not. "Does the story wall appropriately tell our story?" Then we make adjustments (or not). Sometimes, we agree to revisit on a set date. Sometimes, we roll with it knowing we can always change it.

My advice is to use the wall until you've perfected your process and then select the right tool. I've yet to see a team move to a software tool after a few months of working with cards.

In the interest of full disclosure, I did work on a multi-million dollar project with teams in various locations around the world. In this instance, I felt an electronic tool was beneficial as it was a good way to communicate work status across all locations. It created a universal card wall. But even then, we kept the implementation of the tool simple and relied primarily on local card walls allowing each team to design and adjust their own specific process.

The "process" you design must work for your team. Adopting another team's process is an acceptable starting point. Just be certain you adapt and improve as you learn best what works for your unique team in your unique environment. Most tools get in the way of this. All tools offer less flexibility than a blank wall, a roll of painter's tape, and a fist full of index cards.

Motivating the Unmotivated

2010-09-08T17:57:00.001-04:00

I read a post recently from teknophyl entitled "Motivating the Unmotivated". He asked me to read it and give him some feedback. I started a reply in the comments and realized this one was going to take some time.

I encourage you to read his blog entry. I am willing to bet it will resonate with most of you, either as a participant in a similar series of events, or at least as a witness.

The blog entry ends with a question - "what do you do to motivate the person who is seemingly unwilling to be motivated?"

People are complicated

I haven't found anything that works every time. People are complex and difficult to understand. That includes you. And that includes me.

I have a history of failed well intended attempts to motivate people toward goals. But I also have a history of successful attempts to facilitate people's forward progress toward goals.

Dont' Motivate, Facilitate

Motivational techniques employed in the typical worker/manager relationship are often nothing more than coercion hiding behind a more palatable name. The distinction between motivation and coercion is small, but significant. Motivation is providing someone with a compelling enough reason to take action. Coercion is compelling one to action through force, authority, or exploitation. In either case, we are attempting to incite someone to clear a hurdle in order to achieve a desired goal. When we facilitate, we remove the hurdle and clear the path to the goal.

Seek first to understand

What we perceive as lack of motivation is often fear or lack of confidence. A lack of confidence may be in themselves, leadership, or procedures.

Find out what their perspective is. How do they see the situation? How do they see you? What do they fear? What are their concerns? What are their beliefs? Your goal here is not to help them see the flaws in their world view. Your goal here is to understand and accept that their perception, no matter how incongruent with your own, is their reality. It is their truth.

This is not a comfortable task, but it is not all that difficult. You may need the help of a third party, especially if there is interpersonal tension. In order to truly express their concerns, thoughts, and fears, they need to know there are no repercussions for being honest and open. Allow them to express themselves without countering, defending, or attempting to persuade. Listen intently and with an open mind.

Acknowledge their views

Tell them what you heard without judgement or bias. Avoid rephrasing their concerns from your perspective. I've seen people do this exercise and then say things like, "So I heard you say that you don't care to be professional and you don't think you should have to adhere to dress code like the rest of us." when what the person said was, "I am more comfortable in tennis shoes and don't see how footwear matters in the bigger picture." You also need not articulate a punch list of their prior statements. The objective is not to "prove" you listen. The objective is to listen.

Provide them the opportunity to clarify and elaborate. You want to understand their perspective. You want them to know you understand. Rather than tell them, "I understand", allow them to tell you, "Yes, you understand".

Assure them of change

Interpersonal Issues

If you wish to alter the behavior of another, start by altering your own behavior. Let's say that your fellow employee feels you are too critical of their work, they feel you see them as inferior as a result, and they resent that feeling. But you don't feel you are too critical. Rather than attempt to alter their perspective, assure them you will try to be less critical and then genuinely try to do so.

I'll give you a tip here - when making an effort to adjust your behavior, refrain from prefacing your new behavior with statements that point it out. For example, "I know you want me to try to be less critical, so ..." Simply adopt the new behavior.

Organizational Issues

Perhaps they feel they are not empowered to do what is being asked of them. Process requirements or dependence on others outside of the department impede their ability to do their work effectively. Assure them you will work to change those things you feel you can. Statements like, "I'll get Anita to whip her crew into shape or she'll have to deal with my wrath." are obviously grandstanding and represent you as someone who coerces. This devalues the very process you've just gone through. Let them know, "I'll ask Anita if we can get our groups together to discuss each other's needs and come up with something that works for all of us."

Don't make promises you can't keep

Some of what people want cannot or should not be achieved. I do encourage you to question every policy that impedes a team's ability to work more effectively. But sometimes there are valid reasons, be they for safety or legal compliance. If the policy is not based on safety or legal compliance, it is quite likely a placebo for communication.

If what the team or individual desires is not possible, be clear about it. Don't make empty promises. Be forthright and honest.

Ask them to change

Most of us are aware that relationships are multi-dimensional. Knowing we are heard, understood, and supported makes it much easier for us to consent to a little change ourselves. Asking quid pro quo is by no means out of the question. You've agreed to be less critical; ask them to honor core team hours.

Keep it balanced

Whatever they ask of you, you should expect of them. Whatever you ask of them, they should expect of you. Of course there are exceptions; roles, gender, responsibilities all come into play. Often, expectations are identical; honor core hours, don't be late to stand-up. Be cognizant of the amount of commitment each party is making and make a sincere effort to keep it in balance.

Keep your promises

This is critical.

Follow through. Remove the hurdles.

People are skeptical when told "things are going to change around here." Make sure change happens. And make sure it happens quickly. One small change can bring hope and inspiration.

A lack of action breeds contempt and cynicism. Not only have we failed to make things better, but we've made them worse.

Involve people in the removal of the hurdles. Empower people to clear their own blocks. Encourage them to set up the meetings and be there to support them.

Excellent Developers Are the Best Hires

2010-08-14T16:34:00.000-04:00

I recently read a post wherein the author was condoning the hire of excellent programmers with abrasive personalities over bad programmers with cordial personalities. Superficially, I agree with this advice as it is ultimately better to have an individual who does their job well and delivers over an individual who you get along with very well, but who cannot produce.

A false dichotomy

The notion that you must choose between great developers with bad personalities or bad developers with great personalities is just plain false. The dynamics involved are far more complex than that, but let's assume for a brief moment, that there are only two criteria any company hires on; raw skill and congeniality.

The author posits that most companies do not have the luxury of hiring based on both skill and personality. He suggests Google has this luxury and yet they are always looking for good developers. His conclusion is that there are too few developers who are both excellent at the craft and reasonably compatible with the rest of the human race. I submit that perhaps Google's growth rate has contributed to their continual search for developers. I haven't any idea what their turnover rate is, but I do expect it also contributes to the demand.

Let's not forget there are far more developers in the middle of this continuum than on either end-point. I would surmise the majority of developers fall somewhere comfortably in the middle; decent developers with decent personalities. Neither excellent nor awful. Neither completely congenial nor damagingly dissonant. The choice between only the two extremes is invalid.

What makes for an excellent developer?

What are the criteria for excellence when it comes to developers? If we agree that a developer's role is ultimately the consistent delivery of software, then what atributes do we expect an excellent developer to have?

I think there are many facets to what a developer does, but I think we can all agree on three things an excellent developer must be; Knowledgable, Skilled, and Efficient.

Knowledgable

An excellent developer is certainly knowledgable.

Knowing not only a particular language, but multiple languages. An excellent developer knows that the idioms, extractions, and constructs of one language enrich their ability to write code in all languages.

An excellent developer knows that they are not an expert in all languages they use; perhaps (and most likely) in none. An excellent developer knows there is always more to learn. An excellent developer knows lessons can come from anywhere, not only from those they hold in high regard.

An excellent developer is knowledgable in the business domain. An excellent developer can speak with others about the problem at hand in terms everyone is familiar with. An excellent developer knows they should not make unilateral decisions, should not accept decisions from others made in isolation, and should not expect all decisions to be made by committee.

Skilled

Equipped with the knowledge there is always more to learn and always room for improvement, an excellent developer hones their skills. An excellent developer practices their craft. Not just working the same problem with the same tools day in and day out, but working different problems with different tools simply for the pleasure of learning.

An excellent developer does not wait for their employer to approve the budget and time off. An excellent developer takes the initiative and attends conferences, user groups, and weekend gatherings where other practitioners talk, share, and practice.

An excellent developer practices because they want to. An excellent developer improves themselves a little bit every day.

Efficient

For an excellent developer, efficiency is more than writing code quickly. Efficiency is writing code that is easy to maintain in the future. For an excellent developer, efficiency is writing only the code you need today without sacrificing the ability to make alterations tomorrow.

Efficiency is working in a manner that allows any developer on the team to pick up precisely where you left off and see the work to completion.

Excellence Precludes Unsociability

Excellence requires knowledge, skill, and efficiency.

Knowledge requires open mindedness in that one considers what multiple languages have to offer and recognizes that lessons can come from anywhere.

Knowledge requires humility in that one knows they are not expert in all tools they use and that lessons can come from anyone, regardless of status.

Skill requires discipline and commitment in that one must apply themselves not only at work, but outside of work as well; in divergent skills and tools.

Skill requires initiative. An excellent developer does not wait for training to be scheduled and budgets to be approved.

Skill requires social interaction for the best lessons come from the social interaction we have with other developers at conferences, user groups, and weekend events.

Efficiency requires wisdom. The wisdom to know what to build and what not to build. The wisdom to know when the extra effort today is worth the payout of tomorrow and when "good enough" really is.

Efficiency requires teamwork. Developers working in groups, covering each other's back, and sharing ideas as the solutions unfold before them.

If an excellent developer is knowledgable, skilled, and efficient, then an excellent developer is open-minded, humble, disciplined, committed, initiative taking, socially engaged, wise, and team-oriented.

It is, therefor, impossible to hire an excellent developer who has a bad personality.

Roshambo Estimating

2010-08-10T17:38:00.000-04:00

This is a quick post. I just want to share a technique we've been using for initial story estimating. I first used this technique at ThoughtWorks when we were working on a project that required a lot of estimating. I think it came about because 1) we did not have any estimating cards immediately available and 2) that is the kind of place ThoughtWorks is. I later came to discover that the technique is not only fun, but it actually has a few additional benefits.

My recall is fuzzy, but I believe it was Greg "Hippie" Warren who first suggested it. As many of you know, Robshambo has a bit of a tradition at ThoughtWorks (not normally associated with estimating), so it just seemed natural.

How it works

Set-Up

Roshambo Estimating requires no special equipment, only your hands and some partners.

When estimating a story, get a brief overview of the story and acceptance criteria. Ask whatever high-level questions come to mind in order to get a good general sense of the effort required. Do not try to nail down every last detail. It is perfectly acceptable to make some assumptions or leave some unknowns.

Any team member may ask for an estimate at any time. When the team is comfortable giving a rough estimate, throwing may commence.

Throwing

Each team member begins with one hand balled into a fist and resting on the open palm of their other hand. One team member counts to three. At the counts of one and two, team members bang their balled fists into the palm of the open hand. On the three count, all team members "throw" their estimates. Estimates are represented by the number of fingers showing on your hand.

I prefer a Fibonacci sequence as it appropriately represents the proportionality between estimate size and accuracy. So, for the teams I work with, we usually throw a 1, 2, 3, 5 or a thumb.

A throw of 1, 2, 3, or 5 indicates the point estimate for the story. A throw of thumb indicates the story is too large to estimate on one hand.

Evaluation

If the throws are all the same, you have your estimate; move on to the next story.

If there is a significant discrepancy, provide each of the outliers an opportunity to briefly explain their thinking. The team then decides to estimate again or continue discussion. If discussion continues, any team member may ask for an estimate at any time. When the team is comfortable giving a new estimate, throwing may commence.

Typically, the discrepancy is small. Half the team throws a 2 and half the team throws a 3. A quick discussion should resolve this. Often the low estimates round up and the team moves on.

So... what makes this better?

This is not significantly different than a number of other estimating techniques already floating around. So why adopt this one?

In my experience, I've found this to be the fastest and most efficient way to do estimates without sacrificing the quality of the estimates. It can be done at any time, any place. No extra materials required. There is no shuffling of cards, no cheating, no anchoring.

The idea is to get to an estimate quickly and to put primary focus on stories that have discrepancies, therefor requiring more discussion.

It is fun and it looks silly.

This technique implicitly mandates that no stories can be larger than a 5. I recognize every team has their own set of practices around story sizing, but it has been my experience that estimates larger than 5 are significantly less reliable. Effectively, there is minuscule discernible difference between an 8 and a 13 in terms of actual effort required to complete. If I had my way, no stories could be larger than a 3; at which point, we don't need to estimate and can just count cards. - but that is another post for another day.

It's our own damn fault

2010-06-26T11:44:00.010-04:00

It ain't easy slinging code

Over the course of my more than twenty years in the software development industry, I've worked with hundreds if not thousands of developers. Many of the projects I've been involved with have suffered from the same malady; a disconnect between expectations and realistic possibility.

The Agile Manifesto attempts to address many of the root causes of this malady. It encourages individuals to interact, collaborate, communicate, and respond to change. These are not easy things to do. Nor do they necessarily ensure quality software.

The Manifesto for Software Craftsmanship gives a clear nod to the Agile Manifesto and then extends it by addressing the need for quality software. These are not easy things to do.

The man is always keeping us down

Many developers look to this inequity and the challenges and realize they are helpless against unrealistic demands. External forces are at play; leadership, management, or sales - no matter. They neither listen nor care. They want it done. They want it all done. And they want it yesterday.

So we cluster together. We lament. We gnash our teeth. We wring our hands. We commiserate. And then we perform our duties in compliance with the demands set upon us.

It is not our fault. Try as we might, we get no respect. No recognition. No appreciation. If we don't crank fast and put in the long hours, they'll just find somebody who will.

We have no choice.

We are victims.

And we need only for "them" to understand and allow us to do our jobs well.

It's our own damn fault

Where do we get off? Absolving ourselves of responsibility for the quality of our work by blaming others. We rationalize doing a lower quality job in the name of pressures, deadlines, and promises made by others. But it is we who deliver the software. It is we who ultimately make the decision to not test enough, not refactor, put in excessive hours, and not do a quality job.

And every time we do this. Every single time we say it can't be done but then deliver a steaming pile that closely resembles that which we said couldn't be done; we reinforce the behaviors. Every time we put in excessive hours to be heroes, we set a precedent for the next time. Every time we compromise quality in order to meet unrealistic expectations, we devalue ourselves and the service we provide.

We haven't the right to complain about the very behaviors we enable.

Never ask permission...

If we want to stop this pattern. If we want to improve the reputation of our profession. If we want "them" to understand, then we need to change our behavior. Take a stand. Do your job well regardless of the pressure. A doomed project is doomed whether we compromise on our values or not. The more of us who behave this way; the more of us who insist on quality from ourselves and our teammates, the more evident it will become that this is not only a better way, but the right way - perhaps the only way.

Do your job. The absolute best you can. Keep learning. Keep improving.

Never ask permission to do your job well.

Value is more than money

2010-06-08T22:32:00.004-04:00

This got me thinking

Michael Nygard tweeted

'The phrase "business value" seems to hide uncertainty behind vagueness. Can we just say "money" instead?'

I disagree. Or more accurately, I disagree with what I infer Michael means by this single tweet. I cannot say with any certainty what he meant, much less address the context of or inspiration behind his statement.

Greed and Gluttony

To say, "We are in business for profit.", is to say "We live to eat."

This is fundamentally backward. This is beyond misguided for such a perspective is ultimately fatal to any company or person who lives by these respective statements. Undoubtedly, the actions necessary to support the belief will result in a tragic demise, whereby the very thing you identify as your purpose will cause your termination.

These amount to nothing more than rationalizations for greed and gluttony.

Paved with Good Intentions

Of course, it is important that a company generate enough revenue to sustain operations. Without this, the company cannot endure and cannot serve its purpose to humanity, in whatever form that might take. On behalf of every company, therefore, a group, committee, or department must exist whose purpose is oversight of the company's financial wellbeing.

This group has an awesome responsibility. One I am certain they do not take lightly. One I understand they consider paramount. Should they fail, the company will certainly fail. To best ensure success, they might conclude that their responsibility should be shared among all members of the organization.

If a company benefits when only a small portion of its employees commit themselves to a focus on profit, surely increasing this focus will increase the resultant benefit.

Tunnel Vision

Tunnel Vision impedes an organism's ability to see beyond a restricted range due to flaws in the field of vision. This is, clearly, a dangerous affliction. Those who suffer from tunnel vision have diminished peripheral capabilities making them more prone to accidents and providing them less time to react to threats approaching from outside their line of vision. Metaphorically, a company that focuses a preponderance of staff on the "bottom-line" inadvertently (or perhaps intentionally) creates tunnel vision.

Staff learns to weigh all decisions based on short-term ROI. As a result, they seek lower cost (and typically lower quality) support services, try to get by on smaller staff without properly streamlining processes, second guess sales and marketing initiatives, and defer investments in facilities and equipment.

But these efforts result in lower quality products, lower employee satisfaction, and loss of market share. For most companies, these are counter to long-term success.

Value

So if money's not the point, what is?

I can tell you that for LeanDog, the point is to make the world a better place through better software development.

I don't know what the point is where you work. Maybe it is to provide people a more convenient solution to a common problem. Maybe it is to ease people's pain, angst, fear, or concerns. Maybe it is to make people feel better, healthier, happier. I don't know. But I am hopeful the point of your company is not to put money in the pockets of the shareholders.

Story value is in how they serve the purpose

Don't measure the value of your stories in money. Measure the value of your stories in how well they serve the purpose of the organization. And if you can't see the connection between the stories and the purpose of the organization, I'd say that's a project smell. If we don't know how what we are doing furthers the company in the pursuit of its mission, why do it at all?

Take Control of your Development Career

2010-05-19T21:19:00.000-04:00

I got the opportunity to do a little road-trip with my daughter this past weekend. I had an opportunity to speak at the Carolina Code Camp. They accepted all three of my submissions, so I figured I should make the trip. She spent a couple of semesters at High Point University in North Carolina and was looking forward to seeing some friends, so she offered to come along.

The trip was great. We had a total of fourteen hours together in the car, which gave us plenty of time to catch up, talk philosophy, talk a little politics, and just hang out. If you think fourteen hours is a lot of time to fill talking, you haven't met my daughter or me. Separated, we are fairly loquacious, but together, we can get into a zone and move from subject to subject with nary a pause.

The venue was excellent, the weather was beautiful, and the audience very receptive. I gave three presentations; "Introduction to Functional Programming with Scheme", "The Technical Debt Trap", and "Take Control of your Development Career". The last one is brand new. I've included a link to the slide deck.

Take Control Of Your Development Career

View more presentations from Michael Norton.

I like this presentation. I absolutely loved it when Joe O'Brien gave a similar talk at Code Mash and I wanted to do something similar (but unique). Frankly, I think this one needs work. I got very positive feedback at the conference, but I feel like it doesn't deliver what I want it to. Look for changes to this talk in the future. And if you've thoughts on what you'd like to see, feel free to let me know. I think this has a lot of potential, I just don't feel I've nailed it yet.

Cleveland Ruby Group

2010-05-19T13:32:00.000-04:00

Just a quick note:

I have officially accepted the coordinator position for the Cleveland/North East Ohio Ruby Users Group. Many thanks to Joe and Mike for their years of service. This is a good group of local Rubyists, interested in learning and furthering their craft.

The leadership team is now Joe Fiorini, Matt Snyder, and me. We've made a couple of small adjustments to the site and Joe recently launched www.clerb.org. We are looking to the existing community to provide ideas and feedback in order to drive our direction and ensure the group meets the needs of its members.

Visit the Cleveland/North East Ohio Ruby Users Group on meetup and make sure you check out the CleRB.org site.

The Technical Debt Trap

2010-05-02T10:37:00.102-04:00

I had the honor of presenting at Chicago Code Camp this week on the topic of technical debt. For those of you who know me, you know this is a topic I feel passionately about. More accurately, I am concerned about the misunderstandings surrounding technical debt and the frequent use of the term to placate any sense of responsibility over writing messy code in pursuit of a deadline.

The Technical Debt Trap

View more presentations from Michael Norton.

Ward Cunningham

I run the risk of looking like a Cunningham Fanboy with this presentation. I effectively stand in front of the audience and say, "Ward Cunningham says..." I don't know Ward personally, but I wouldn't mind meeting him some day. His insights on the development process and our responsibilities as developers are keen, his message is clear, and it is way easier to appeal to authority than to convince people to listen to me.

References

There are a number of references in this slide deck. I've included all of the links along with a brief explanation of each.

OOPSLA '92 Experience Report
Ward Cunningham's brief on the WyCash Portfolio Management System wherein he likens shipping first time code to going into debt and warns of the potential pitfalls.

James Shore on Voluntary Technical Debt
James talks about how a savvy team can use technical debt as a tool to accomplish more than they otherwise would.

David Laribee on Paying Back Technical Debt
David discusses the burden of Technical Debt on a project team and the use of agile practices to pay the debt down.

Steve McConnell on Technical Debt
Steve focuses on an approach to technical debt from a business perspective, looking at decisions to incur debt, how to ensure it is the right kind of debt, and how to service the debt.

Martin Fowler expands the Metaphor
Martin has several entries on Technical Debt. In this particular entry, Martin refers to Ward's definition of technical debt and provides a condensed definition that I believe could be the most often referred to definition.

Ward's Video Statement
Ward creates a video wherein he discusses the technical debt metaphor and explains his views on messy code as it applies to technical debt.

Ward Tweets about Technical Debt
Dirty code is to technical debt as the pawn broker is to financial debt. Don't think you are ever going to get your code back.

Continuous Refactoring and ROI
The team over at Software Management Blog explain how to use continuous refactoring to keep your technical debt down and shows the flaw in scheduling refactoring into large concentrated efforts.

Optimal pairing

2010-04-20T20:42:00.001-04:00

What was all that rambling about Harmonic Mean?

A while back, I posted a rambling entry about the impact of Harmonic Mean on a team's performance. The post was actually about pairing. My intention was to put a solid mathematical, albeit only pseudo-scientific, explanation behind my paring recommendation, but I think I lost several people (including myself once or twice) in the math and all the fancy words.

In short, whenever you pair two people of disparate skill sets, their contribution to production is more heavily influenced by the lesser skilled or experienced of the two. And the impact is significant. The greater the disparity in skill/experience, the more significant the impact.

Pair with people of similar skill and experience

Maximum performance per pair is achieved when the pairs have identical skills and experience. This is, of course, highly unlikely. It is, however, fairly easy to put together a team with similar skills and experience. This provides us an opportunity to mix pairs, keep things fresh, and disseminate knowledge and experience more rapidly through the team without concern over the impact of mis-matched pairs.

When putting a team together, it is best to make sure the skill sets are within a few degrees of one another. When this is not possible, work to achieve a fairly even distribution of skill and experience. Avoid large gaps and do your best not to leave anyone isolated at the ends of the scale.

Exceptions to the "rule"?

The Software Craftsmanship movement encourages us to apprentice people new to software development. To bring them in, take them under our wing, and provide them the opportunity to learn through direct interaction with other developers in a structured and meaningful way.

Surely, Doc, you are not suggesting that apprentices should teach one another.

Yes, I am.

First of all, a good apprentice program does not immediately toss the new hire into a high-demand deliverable project. A good program provides the apprentice an environment where they can work on breakable toys designed to help learn fundamental concepts. Each step is a building block to the next, wherein fundamentals in both theory and practice are learned and built upon.

Under these conditions, who better to pair with than another individual of similar skill and experience? You can discuss, debate, discover, and learn all under the watchful eye and guiding hand of a more experienced journeyman or craftsman. The master cannot and should not devote his entire time to the growth of the apprentice. It is optimal, even as someone brand new to the craft, to pair with another much like yourself.

Chicago Clojure Group

2010-04-19T16:26:00.001-04:00

I am new to Clojure, but when I was asked to help with the Chicago Clojure Group, I was certainly willing to give a hand.

It took me a while to get my act together and whether or not it is entirely together is yet to be seen, but I am happy to announce the re-launch of the Chicago Clojure Group.

You can find out more about the group and our events on the official meetup site.

http://www.meetup.com/Chicago-Clojure/

Hope to see you there.

Apprenticeship Patterns

2010-04-10T09:57:00.001-04:00

Apprenticeship Patterns is a book of common sense advice derived from years of experience. While it reflects experiences, lessons learned, and patterns derived from the profession of software development, this is really a book about how to craft your own successful career, regardless of chosen vocation.

Each chapter of the book introduces us to new, related patterns. Patterns progress as if in a timeline from those you will find most valuable starting out to those which foster continued growth and learning for a lifetime. The patterns themselves are atomic so while the progression in the book is logical, it is not necessary to read the book front to back. From the last pattern to the first, each is applicable whether you are just starting or are a seasoned veteran.

I recommend Apprenticeship Patterns to everyone, not just friends in the computer industry.

Stories are about why; not what or how

2010-04-07T15:32:00.001-04:00

Story Fomats

I've been on numerous Agile projects with varying methods for capturing stories. Quite popular (and purportedly the ThoughtWorks standard) is the "As a, I want, So that" story format.

While I have seen teams do well with this format, I think it can be radically improved with a minor change. I prefer to see "So that, as a, I want" story format.

My reasoning is quite simple; the emphasis is incorrect in the common story format.

Same words, different order

Compare these two statements:

As A Bank Teller, I Want a name search field, So That I can quickly look up customers.
So That I can quickly look up customers, As A Bank Teller, I Want a name search field.

These are arguably the same story. The words are precisely the same; merely in a different order. Pick them apart, word by word, and we all agree these requirements are identical.

Emphasis

But in planning meetings and even our regular work lives, we don't pick each statement apart word by word. Rather we take in the statement linearly, process it for meaning as we go, draw a conclusion of intent, and act.

Let me make it visibly clear what is happening in our minds as we process the two statements:

As a, I want, so that
So that, as a, I want

"As a" is always secondary in our mental process. This is, of course, a generalization. If I am an account manager, I am highly attuned to all "As an Account Manager" stories. But on the whole, for whom is a clarifier, not a primary consideration.

With the common story format, our discussion is likely to be more around what the text field will look like, where it will be on the screen, and how it will function.

With the common story format, I often see stories devolve to the abbreviated, "As a, I want" form. This is quite dangerous. We are now delivering functionality that serves no expressed purpose.

Focus on Why (value)

By placing "So that" at the front of the statement, we've put an emphasis on why the story exists. If we can't say why we are implementing a feature, there is clearly no purpose for the feature. Even when we are certain that the purpose is obvious, it is best to include it. What is clear to the requestor may be opaque to the implementor.

Our discussions are now focused on value. We may spend no less time discussing specifics of the implementation, but we are first assured we know why we are delivering the story. Our implementation is better guided by why. We are free to explore alternatives that better suite the purpose.

Put purpose first; literally and figuratively

It helps to put the purpose of the story at the front of the story form. It places the proper emphasis on why and better frames our discussions. But if the purpose is inadequately stated, we are still likely to have the wrong discussions.

Take the time to genuinely consider the why of each story. What is the value to the business? How will the customer be able to confidently select this story over another in planning sessions? Consider using Vincent Partington's technique for creating clear stories.

Our original story is better stated as follows:

So That I can serve customers faster, As A Bank Teller, I Want an efficient way to look up customers.

We now express the actual value to our client and we do not mandate implementation in the story summary.

Making Your Customers Pay for Your Shortcomings

2010-03-24T22:04:00.000-04:00

This one is a straight-up rant. Because this announcement incenses me.

AT&T Set to Roll Out Nationwide 3G MicroCell Availability Beginning Next Month
AT&T to begin nationwide rollout of 3G MicroCell in mid-April

Here is the letter that should accompany this announcement in next month's mailer to all AT&T customers:

Dear consumer:

We know our coverage is severely lacking. We've put a great deal of money into running ads to spin the facts and make it look like we have coverage comparable to our competitors. But that isn't helping because, well, our crappy coverage is a fact, not an opinion.

So now we have a new plan that we think you will really like. Rather than investing in our network to provide you the coverage you rightfully expect, we will instead take more of your money in exchange for which we will provide a device that allows you to use somebody else's network. We will, however, continue to charge you for these calls because you are using the micro device you purchased from us. Worry not, we've devised a month to month plan where you can pay us one flat monthly fee to use the device you purchased to make up for the crappy coverage we provided you in the first place.

This is what we call a win-win situation. You pay us more money and we give you effectively nothing in exchange for it.

Thank you for your continued patronage and bags of money.

Sincerely,

AT&T

Harmonic Mean is a Bitch

2010-03-16T10:27:00.149-04:00

The Theory of the Weakest Link

A chain is no stronger than its weakest link, and life is after all a chain. - William James

A chain is no stronger than its weakest link. Metaphorically, this applies to teams. But in actuality, this is simply not the case. Humans have not only tenacity, but the ability to countervail one another. This is a quality that inanimate objects simply do not possess. We can and will compensate for one another for the good of the team. Links in a chain are incapable of sharing their strength. No other link can compensate for the weakest.

The key is knowing how to compensate.

Applying Averages

Quantifying Ability

So perhaps the weakest link theory does not apply. But you can't argue with math, right? Quantify each team members ability, average them together, and you get the normalized ability of the team.

On a scale of 1 to 10 in some arbitrary (but extremely meaningful and accurate) quantitive skill measurement:

Name   Ability
Alex       7
Casey      3
Chris     10
Jessie     4
Leslie     8
Logan      2
Pat        8

The Arithmetic Mean (Average) for the team is 6. Assume our scale is congruent with percentiles where 5 is average. We have a team that contains a clear prodigy and three above average individuals, yet the team's ability is barely above average.

Quantifying Delivery

I don't have a lot of respect for talent. Talent is genetic. It's what you do with it that counts. - Martin Ritt

This scale means nothing to us. Average ability? How does that map to work completed? Making it happen is where it's at, baby.

Let's assume for a second that our ability scale conveniently transfers to points per week completed.

Name   Points/Week
Alex       7
Casey      3
Chris     10
Jessie     4
Leslie     8
Logan      2
Pat        8

Again, the Arithmetic Mean for the team is 6. Nothing changed. What's your point, Doc?

Fair enough. There is no difference. But wait, there's more!

Accounting for Counter-vailing

We discussed earlier in the theory of the weakest link that man is capable of compensating for one another, thereby raising the strength of the weakest point in the group. Something a chain can never do. And this is a beautiful characteristic. But is it enough? And how does it work?

To be fair, we should assume that in covering for someone else, we diminish our own performance. If I assist you in completing a point, I sacrifice some of my own delivery rate. While I can certainly work a few extra hours to make it up, that pace is not sustainable.

We adjust the points per week. Our top performer is now our team lead. The top performer contributes two points to the others and our other high performers provide one each. The new scale looks like this:

Name   Points/Week
Alex       6
Casey      5
Chris      8
Jessie     5
Leslie     7
Logan      4
Pat        7

And our average for the team is still 6.

This sure would be swell, Wally. But their just ain't no way. I think something is wrong with the Beaver....

If we are pairing people up and one of the members has to effectively carry the other, there has to be some loss of velocity. If, however, we don't pair, we end up with a lot of re-work and lower performers stay lower performers for much longer. If you are in the camp who believes pairing is a bad practice, you will likely find significant ammunition in this article. I, however, do believe pairing is a fantastic practice. The dividends of pairing are significant and outside the scope of this article.

Getting the math right

Each developer is capable of completing a single point in some period of time. We can extrapolate that to points per week. When two developers share the work, we average the rates together. But now we have an interesting twist. We are trying to determine how long it will take these two developers to complete a single point, assuming they evenly share the load of that point between the two of them. This average is not determined by Arithmetic Mean, but by Harmonic Mean.

Digression into Harmonic Mean

Let me see if I can explain this.

You drive from your home to the store, which is exactly one mile, in exactly 4 minutes.
1 mile in 4 minutes is .25 miles per minute, which is 15 miles per hour.
You drove to the store at 15 miles per hour.

You return from the store along the exact same route, but this time it takes exactly 3 minutes.
1 mile in 3 minutes is .333 miles per minute, which is 20 miles per hour.
You drove back home at 20 miles per hour.

For the complete round trip, you drove 2 miles in 7 minutes.
2 miles in 7 minutes is .2857 miles per minute, which is 17.143 miles per hour.

Your average speed is not 17.5 miles/hour, but 17.143 miles/hour.

Back to our developers

This applies similarly to our developers.

Chris delivers one point in .5 days, which is 10 points/week.
Logan delivers one point in 2.5 days, which is 2 points/week.
Together, they complete 2 points in 3 days, which is 3.33 points/week.

As long as Chris and Logan are paired with Chris compensating for Logan as opposed to each of them augmenting the other, their average rate is 3.33 points/week. So we drop one of them from the Arithmetic Mean calculation.

So what does this do?

Name   Points/Week
Alex       7
Casey      4
Chris   3.33
Jessie     4
Leslie     7

Pat        7

The average for the team is now 5.39

Harmonic Mean is a Bitch

Harmonic mean lessens the impact of higher outliers, while emphasizing the impact of the lower numbers, especially as compared to Arithmetic Mean. So Harmonic mean favors the lower numbers. If this is true, doesn't it make more sense to have one of our slightly above average developers help train Logan instead?

Let's ask Alex to do it.

Alex can complete 1 point in 1.4 days.
Logan can complete 1 point in 2.5 days.
Together they complete 2 points in 3.9 days.

They have an average of 2.56 points/week.

Name   Points/Week
Alex    2.56
Casey      4
Chris     10
Jessie     4
Leslie     7

Pat        7

The average for the team is now 5.76

It does make more sense to have Alex pair with Logan. Theoretically, we could improve even more if we ask Casey or Jessie to pair with Logan. But now we are pairing all of our lesser performers together. Probably not a good idea.

Work Together

While my explanation may be a bit complex, my point is simple. You get a better return when everyone on the team pitches in and helps out. And you get a better return if you focus on pulling up the bottom numbers without significantly dropping the top numbers.

I am not advocating that you should only hire "top performers". If you do not grow your team from within, you fail to establish a sense of connection and purpose. And you set yourself up for huge salaries, huge egos, and ultimately high turn-over.

I am not suggesting you should silo your top performers and do not allow anyone to "bother" them. Not only will you have ego issues, but you will have established a cast class for the developers that will be difficult to break out of.

Most organizations take the top performers and put them in leadership roles where they are able to mentor and guide others. A single performer is expected to assist the entire team. Inevitably, those who require the most assistance, get it. We see an improvement as we pull the bottom up, but it is not nearly as significant an improvement as when each level pulls the one beneath it.

Don't blindly put your top performer in charge of the team. Odds are, they will not enjoy the role and your return will be less than optimal. Have the team work together. Encourage pairs with low performance disparity. Make sure your best performers pair with the next level down and so on.

Caution: Metrics change behavior

2010-03-10T00:37:00.003-05:00

Measuring and reporting are important

I've often heard said, "That which you cannot measure, you cannot improve." And while I do believe this is a general truth, I think it fails to tell the entire story. It is not just about what we can measure, but what we actually do measure that is significant; "That which is reported, will improve."

What is not measurable, make measurable. -- Galileo Galilei 1564-1642.

Measuring and reporting influence behavior

Metrics give us feedback. Metrics show a measure of progress toward our goals. Metrics remind us what is most important. Visible metrics, ala Big Visible Charts, help to focus the team on what is most important.

...if I have quick access to key metrics every day, my creativity stays within certain bounds – my ideas all center on how to achieve our goals. -- Paul B. Allen

Access to key metrics provides an individual or a team a quick means of assessing progress and focusing their minds on what is most important. These can be excellent tools for influencing a team toward a desired goal or level of performance.

But the outcome is not always what we intend.

The Hawthorne Effect

There is a now famous study that was done in the early 1900s. Hawthorne Works commissioned a study of the effects of ambient lighting on worker productivity. The results of the test were perplexing. Essentially, worker throughput seemed to increase despite the level of light. High, low, medium; with each change, throughput increased. Once the study was concluded, levels quickly fell back to "normal".

The are several criticisms of this particular study, but the phenomenon has been repeated under different circumstances since.

The conclusion; that which was measured, improved. Effectively, because people were aware their throughput was being measured, it increased. In similar studies, people's throughput increased when they were knowingly observed but received no guidance or feedback. So they assumed throughput was the objective.

Rock On! Where is my plotter?

So this is pretty awesome, huh? Just let people know you are watching them and their productivity will soar! Throw up a few charts and you've got yourself a high-functioning team.

You wish

So here's the rub. An increase in throughput is not necessarily a good thing.

Why Not?

Do you believe your employees are slackers?
Do you think they lollygag about all morning, marking time until lunch and then perhaps featherbed it to 5pm before they skedaddle out the door?

If you do, then you have a significant problem. A problem that a few charts and some good old fashioned micro-management probably won't solve. But, hey, it is worth a try....

Our employees suck less than that

Good. So you have a reliable, forthright, responsible team of people. If this is the case, then you might do well to be a bit leery of easy increases in throughput. I'm not saying it is a bad thing, but that extra throughput had to originate somewhere. Perhaps it is less time spent in needless meetings. Perhaps it is better attention to priority items. If so...

Huzzah for metrics!

BUT...

You've been warned

That which you measure and report will improve.

If what you track and report is one-sided, your results will be one-sided.

When you are on an agile team and all of your metrics are about velocity, you send a clear message to the team.

Go Faster! quality ain't all that important and value don't matter

Goodhart's Law

Goodhart's Law is a principle first defined in 1975 in a paper by Charles Goodhart, chief economic advisor to the Bank of England. Goodhart's basic premise is that economic indicators made into targets for the purpose of conducting economic policy, thereby lose their ability to serve in the desired capacity.

More succinctly put - When a measure becomes a target, it ceases to be a good measure.

Goodhart's law is applicable to both economics and sociology. It is a proven fact (law) that when you take an indicator such as velocity and you make it a target, you thereby eliminate it as a valid indicator.

Good Metrics

Measure value, not throughput. How many of the high-value stories were delivered, regardless of points.

Focus on your customer's determination of value. How do your metrics tie directly to their single highest priority?

Study trends, not moments in time.

Use metrics as a diagnostic tool. When a problem is identified, devise one or two metrics that will help diagnose and monitor the health of the issue. When resolved, stop measuring.

Do not record or report metrics for reporting sake.

Do not set targets for your metrics.

If you must report velocity, report only team velocity.

Contributing to a project you find on GitHub

2010-02-26T19:03:00.005-05:00

For the purpose of this article, I assume you have git installed, have a GitHub account, and are fundamentally familiar git.

You've been exploring GitHub and have discovered a project you want to contribute to. Let's say it is my fork of the Functional Koans. You want to add some flair to the Python Koans in particular.

Fork the DocOnDev project

To create a fork, press the "fork" button on the project's page.

When the fork is complete, you will have a copy of the project in your repositories listing.

Clone your project

Now you need to clone your fork. Make sure you use the “Your Clone URL” and not the “Public Clone URL”. You want to be able to push changes back to your own repository.

$ git clone git@github.com:[your-github-account]/functional-koans.git

Once the clone is complete your repo will have a remote named “origin” that points to your fork on github. You will use "origin" for your own regular activities.

Get the source

Let's make sure we have the python source.

$ cd functional-koans
$ git checkout -b python
$ git pull origin python
From git@github.com:[your-github-account]/functional-koans
 * branch            python    -> FETCH_HEAD
Auto-merging README.markdown
CONFLICT (add/add): Merge conflict in README.markdown
Automatic merge failed; fix conflicts and then commit the result.

Ugh. File conflict. No worries, open the file and edit it to look like this:

# Functional Koans


### About the Koans

There are several functional languages that have contributed their own
versions of the koans.  Each language has it's own branch with
detailed instructions on how to get started.

### Getting Started

To get the koans for a particular language, simply clone the repo and
checkout the branch:

'git clone git://github.com/relevance/functional-koans.git' 
'git checkout branch -b [branch_name]'
'git pull origin [branch_name]'


where [branch_name] is the name of the branch (language) you want to
work on.  To get a list of all branches run:

'git branch -a'

Now add the changed file to the python branch and check it in

$ git add README.markdown
$ git commit -m'Fixed README conflict'

Add a remote to the original project

First, switch back to the master branch locally.

$ git checkout master

Then let's take a look at all of our branches.

$ git branch -a
* master
  python
  origin/FSharp
  origin/HEAD
  origin/clojure
  origin/master
  origin/scala

We see that the origin (your repository) has all of the branches, but our local repository only has master and python. The asterisk next to master indicates this is our active branch.

Let's add another remote that points to the source you originally forked from. You can call this remote anything you want. I suggest you use something that makes sense to you. In GitHub's examples, they use the name "upstream", but that I find that to be too general. I tend to name this remote after the original account I forked from. So for the sake of this example, we will use my convention:

$ git remote add DocOnDev git://github.com/DocOnDev/functional-koans.git

You may have noticed that we used the public clone URL for DocOnDev. Truth is, he probably won't give you access to push changes directly to his repository anyway. I heard he's a real jerk about that stuff. And if he had given you access to push directly to his repo, why did you create a fork...?

Just to be sure...

Ok, so we just forked the code, but let's make sure we have the absolute latest version from DocOnDev before we start hacking away. We are going to fetch the latest from DocOnDev. Fetch grabs the latest source from all branches in DocOnDev's functional-koans repo and brings them down to us.

$ git fetch DocOnDev
From git://github.com/DocOnDev/functional-koans
 * [new branch]      FSharp     -> DocOnDev/FSharp
 * [new branch]      clojure    -> DocOnDev/clojure
 * [new branch]      master     -> DocOnDev/master
 * [new branch]      python     -> DocOnDev/python
 * [new branch]      scala      -> DocOnDev/scala

Now if we take another look at the branches...

$ git branch -a
* master
  python
  origin/FSharp
  origin/HEAD
  origin/clojure
  origin/master
  origin/python
  origin/scala
  DocOnDev/FSharp
  DocOnDev/clojure
  DocOnDev/master
  DocOnDev/python
  DocOnDev/scala

Make your changes

You are now free to make your changes and updates. You can add functionality, refactor, whatever it was that inspired you to contribute to this project in the first place.

Make sure you are cognizant of the various branches. Don't make changes in python branch, switch to master branch, and commit unless you absolutely intend to add the file to the master branch. Check in early and often. And of course, write your tests first. ;)

Check in every so often and fetch (or pull) any changes DocOnDev may have committed.

$ git checkout python
$ git fetch DocOnDev python
From git://github.com/DocOnDev/functional-koans
 * branch            python     -> FETCH_HEAD

Request a Pull

You've completed your changes and you'd like DocOnDev to take a look at them and consider them for addition to the project. Simply navigate to your fork and use the "Pull Request" button. You can explain your changes to DocOnDev as a part of the request.

And that's the basics of it. It may take a while to get used to working on a project with multiple branches and multiple committers. I know I hozed my repo more than once before I got the hang of it.

Python String Calculator Kata - Step by Step

2010-02-09T19:37:00.003-05:00

Background

For the past week, I have been working on the String Calculator Kata in Python. I watched Gary Bernhardt's version of it and then set out to tackle it myself. Not surprisingly, my solution was much like Gary's.

Of course, watching a master was a bit of a cheat. I hadn't really figured it out. I just saw what he did and mimicked it. I certainly understood what he was doing and I understood the solution I subsequently developed, but I skipped a very important part of the process; the discovery and real learning.

My wife has taken an interest in software development and is considering a possible career change. Along with reading books like "Apprenticeship Patterns", "The Inmates are Running The Asylum", and "Hackers and Painters", she is learning Python.

I decided that the String Calculator Kata would be a good exercise for us to pair on. I could show her some tricks and help her along. This would be a great learning exercise for the both of us.

Kata

Take One

Our first attempt was over the phone with a screen share. I did all the talking and typing while she watched, listened, and provided me with the occasional, "uh-huh" to let me know she was still there. All in all, I'd say it was a fair experience at best. In my opinion, I had shown her quite a bit, but had actually taught her nothing. She wasn't going to benefit from doing a Kata by rote. She needed to understand how the moves came to be and why they were being done.

This was going to take more time.

Take Two

Our second attempt was in person, side by side, sharing a single computer. I still did most of the talking and all of the typing, but the dynamic was very different. Jennifer was able to ask questions, point at the screen, and interact unlike with the screen share. And I took a much more deliberate approach to the Kata. Making no assumptions about the language; acting as if I were learning it all for the first time as well.

This was a good learning experience for both of us. I learned new things about Python and I felt connected to the developer I once was; the guy who would explore a language for the best way to do something; the guy who would spend hours on the same few lines of code in an effort to get them perfect. I've been doing Kata on and off for about a year with a recent deliberateness. But it wasn't until I used it to teach someone else that I achieved the next level of enlightenment.

After some more thought, I decided to recount the entire experience on my blog. I've already discussed Kata in a couple of posts. The string calculator can be found in Scheme and Python on my github. But none of these capture my thought process. I am not saying my thought process is right. Hell, I have no idea. But I think sharing it and soliciting feedback can't hurt.

The full experience

We start, of course, with a single test.

calc_test.py

import nose.tools
from calc import add

def test_empty_string_is_0():
    assert 0 == add('')

This fails as expected. And we write our add method.

calc.py

def add(input_string):
    return 0

We add the next test

calc_test.py

import nose.tools
from calc import add

def test_empty_string_is_0():
    assert 0 == add('')

def test_single_number_returns_value():
    assert 1 == add('1')

Which forces the change:

calc.py

def add(string):
    if string:
        return 1
    else:
        return 0

But this doesn't cover any single number, it covers a particular single number. So let's update the test.

calc_test.py

import nose.tools
from calc import add

def test_empty_string_is_0():
    assert 0 == add('')

def test_single_number_returns_value():
    assert 1 == add('1')
    assert 10 == add('10')

Our code fails again and we need to figure out a way to return the value of a string. Naturally, I asked the googles. They don't know anything themselves, but they always know somebody who knows something.

A tiny bit of poking around, and I found there is a string.atoi(s[, base]) function, but it was deprecated in verison 2.0 in favor of the built-in int() function. This is what we are looking for:

calc.py

def add(string):
    if string:
        return int(string)
    else:
        return 0

Now the test passes, but I want to get cute. I want to eliminate the if/else. I happen to know Python has lambda capability. So I do some research and refactor to:

calc.py

def add(string):
    return string and int(string) or 0

Cute. Yep.

Back to business. We've covered the first couple of criteria, but we now need to handle more than one item. So we write the test (of course).

calc_test.py

import nose.tools
from calc import add

def test_empty_string_is_0():
    assert 0 == add('')

def test_single_number_returns_value():
    assert 1 == add('1')
    assert 10 == add('10')

def test_multiple_numbers_returns_sum():
    assert 3 == add('1,2')

The familiar taste of failure leads us in search of an answer. How do we get the values out of a string? As it turns out, str is a sequence type in Python. So we can refer to its elements fairly easily.

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    return int(string[0]) + int(string[2])

This gives a string index out of range error on our earlier passing tests. This won't do. We need to refer to the individual values only if there is a comma in the string. Looking back at our reference for sequence types, we find the in operator, which is perfect for this case.

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    if ',' in string:
        return int(string[0]) + int(string[2])
    else:
        return int(string)

This works. Let's see how far we can get using lambda expressions (for fun). Refactor to lambda:

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    return ',' in string and int(string[0]) + int(string[2]) or int(string)

But what happens when the integers are more than a single digit? This calls for a new test.

calc_test.py

import nose.tools
from calc import add

def test_empty_string_is_0():
    assert 0 == add('')

def test_single_number_returns_value():
    assert 1 == add('1')
    assert 10 == add('10')

def test_multiple_numbers_returns_sum():
    assert 3 == add('1,2')
    assert 15 == add('10,5')

This fails with a ValueError. It appears to be trying to get the int() value of a comma. So our hard-coded string offsets won't do. Then what else can we do here?

Perusal of the standard string methods, leads us to the built-in partition method that was added in version 2.5. If it was recently added, it must be what we need....

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    return ',' in string and _sum_delimited_string(string) or int(string)

def _sum_delimited_string(string):
    string_parts = string.partition(',')
    return int(string_parts[0]) + int(string_parts[2])

And the tests pass. But my wife points out this won't work for strings with more than two digits.
Hmmmm....
Let's confirm the assumption.

calc_test.py

import nose.tools
from calc import add

def test_empty_string_is_0():
    assert 0 == add('')

def test_single_number_returns_value():
    assert 1 == add('1')
    assert 10 == add('10')

def test_multiple_numbers_returns_sum():
    assert 3 == add('1,2')
    assert 15 == add('10,5')
    assert 25 == add('10,3,12')

She was right. We get another ValueError. This time we are trying to get the int() of '3,12'. I see an immediate solution that should work. A little recursion and we are good to go.

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    return ',' in string and _sum_delimited_string(string) or int(string)

def _sum_delimited_string(string):
    string_parts = string.partition(',')
    return int(string_parts[0]) + _sum_string(string_parts[2])

And once again, our tests pass.

At this point, I am actively holding myself back. I don't like this form of recursion. If I'm going to do it, I want it all contained in a single function. I really want to use split(), map(), and sum(), but I must remember that we've not discovered these yet. We are solving the problem with what we currently "know".

Roy's first two requirements down, now we move on to custom delimiters; starting with a new-line as a delimiter.

calc_test.py

import nose.tools
from calc import add

def test_empty_string_is_0():
    assert 0 == add('')

def test_single_number_returns_value():
    assert 1 == add('1')
    assert 10 == add('10')

def test_multiple_numbers_returns_sum():
    assert 3 == add('1,2')
    assert 15 == add('10,5')
    assert 25 == add('10,3,12')

def test_newline_is_a_delimiter():
    assert 6 == add('1\n2,3')

Now we get a ValueError on an attempt to get int() for '1\n2'. Let's update the code to get this to pass.

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    return ',' in string and _sum_delimited_string(string) or int(string)

def _sum_delimited_string(string):
    string = _normalize_delimiters(string)
    string_parts = string.partition(',')
    return int(string_parts[0]) + _sum_string(string_parts[2])

def _normalize_delimiters(string):
    return string.replace('\n', ',')

We are back to green. We are moving on to the fourth requirement; custom delimiters. This requirement reads as follows:

Allow the Add method to handle a different delimiter:

to change a delimiter, the beginning of the string will contain a separate line that looks like this: “//[delimiter]\n[numbers…]” for example “//;\n1;2” should return three where the default delimiter is ‘;’ .
the first line is optional. all existing scenarios should still be supported

First the test.

calc_test.py

import nose.tools
from calc import add

def test_empty_string_is_0():
    assert 0 == add('')

def test_single_number_returns_value():
    assert 1 == add('1')
    assert 10 == add('10')

def test_multiple_numbers_returns_sum():
    assert 3 == add('1,2')
    assert 15 == add('10,5')
    assert 25 == add('10,3,12')

def test_newline_is_a_delimiter():
    assert 6 == add('1\n2,3')

def test_allow_custom_delimiter():
    assert 3 == add('//;\n1;2')

And now the code.

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    return ',' in string and _sum_delimited_string(string) or int(string)

def _sum_delimited_string(string):
    string = _normalize_delimiters(string)
    string_parts = string.partition(',')
    return int(string_parts[0]) + _sum_string(string_parts[2])

def _normalize_delimiters(string):
    if string.startswith('//'):
        string_parts = string.partition('\n')
        delimiter = string_parts[0]
        delimiter = delimiter[2:]
        string = string_parts[2].replace(delimiter, ',')
    return string.replace('\n', ',')

This fails, a bit unexpectedly. What went wrong here? The custom delimiter is not being parsed.

A little inspection and we realize that _sum_string() is to blame. Or more accurately, we see that we need to normalize the delimiters earlier in the process. So we move that call from _sum_delimited_string() into _sum_string(), which seems to make more sense anyway.

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    string = _normalize_delimiters(string)
    return ',' in string and _sum_delimited_string(string) or int(string)

def _sum_delimited_string(string):
    string_parts = string.partition(',')
    return int(string_parts[0]) + _sum_string(string_parts[2])

def _normalize_delimiters(string):
    if string.startswith('//'):
        string_parts = string.partition('\n')
        delimiter = string_parts[0]
        delimiter = delimiter[2:]
        string = string_parts[2].replace(delimiter, ',')
    return string.replace('\n', ',')

We are green again, but I don't think I can take it anymore. Look at all those [n] references in the code. And while I am not terribly concerned about it, the recursion could give us trouble on huge strings. There has to be a better way to do this.

So let's go back to the documentation and see if there is anything else we can use to assist us along. One of our problems is the partition breaks the string into three chunks. Maybe something that gives us just the values and strips out the delimiter. Or maybe something that breaks it into multiple chunks.

We discover split(). This appears to have some promise. It can chunk up the entire string into a list. That's nice. Maybe we can ditch the recursive call.

First round, let's get rid of the partition() call and replace it with split().

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    string = _normalize_delimiters(string)
    return ',' in string and _sum_delimited_string(string) or int(string)

def _sum_delimited_string(string):
    string_parts = string.split(',', 1)
    return int(string_parts[0]) + _sum_string(string_parts[1])

def _normalize_delimiters(string):
    if string.startswith('//'):
        delimiter, string = string.split('\n', 1)
        delimiter = delimiter[2:]
        string = string.replace(delimiter, ',')
    return string.replace('\n', ',')

But this didn't seem to do anything for us. The code doesn't really look any better. And it still "feels" messy. We've two different functions that both claim to sum a string, but only one of them actually does. And these functions call one another. Let's push the responsibility back into a single function and see if we can clean this up.

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    string = _normalize_delimiters(string)
    if ',' in string:
        string_parts = string.split(',', 1)
        return int(string_parts[0]) + _sum_string(string_parts[1])
    else:
        return int(string)

def _normalize_delimiters(string):
    if string.startswith('//'):
        delimiter, string = string.split('\n', 1)
        delimiter = delimiter[2:]
        string = string.replace(delimiter, ',')
    return string.replace('\n', ',')

That is better. But isn't that recursive call really just iterating over the list and converting everything to an int() and then adding them up? Looks a bit like a Scheme function with string_parts[0] and string_parts[1] in place of car and cdr. I know this is crying out for a map, but how do I explain this to Jennifer? How do we naturally stumble upon the solution?

So we focus in on the split() function. What does this do? It returns a list of the words in a string. So we dig into lists a bit to learn what they are all about. And we find there are a few functions that are very useful with lists: filter(), map(), and reduce(). Of these, map() and reduce() look like they might do us some good.

We can use map() to convert our list of strings to a list of integers. Then, we can use reduce() to add them all up. Sound good? Yes. Yes it does. But when we check the syntax on reduce(), we see a note that says to use the sum() function for adding items in a list.

And we've arrived at our intended destination.

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    string = _normalize_delimiters(string)
    if ',' in string:
        return sum(map(int, string.split(',')))
    else:
        return int(string)

def _normalize_delimiters(string):
    if string.startswith('//'):
        delimiter, string = string.split('\n', 1)
        delimiter = delimiter[2:]
        string = string.replace(delimiter, ',')
    return string.replace('\n', ',')

That looks a little better. And all tests still pass. Now, let's refactor some more to make it a bit more terse.

calc.py

def add(string):
    return string and _sum_string(string) or 0

def _sum_string(string):
    string = _normalize_delimiters(string)
    return ',' in string and sum(map(int, string.split(','))) or int(string)

def _normalize_delimiters(string):
    if string.startswith('//'):
        delimiter, string = string.split('\n', 1)
        string = string.replace(delimiter[2:], ',')
    return string.replace('\n', ',')

We decided this was a good breaking point for the session. We'd covered a lot of new material in a relatively short period of time.

Tonight, we do it again, starting over from scratch. And I suspect we will skip some of the steps as we already know map() is our desired route.

Introduction To Functional Programming with Scheme

2010-01-17T17:50:00.005-05:00

I had the honor of presenting at CodeMash 2.0.1.0 this year on Functional Programming in Scheme. Given I picked up Scheme only a few months ago, I thought it best I do an introduction. Hopefully, I will have opportunity to do more presentations on Scheme, Lisp, and Clojure.

As you can see by the slide deck, I have more than 60 slides to get through in no more than 60 minutes. The idea was a relatively fluid presentation where the slides continued to change as I spoke. I had some technical difficulties, which I admittedly did not handle as well as I could have. The audience was patient with me and we were able to cover all of the material including some Q&A within the allotted one hour.

I do hope the session was of value to those in attendance. I had to leave immediately after the presentation to make it to a ThoughtWorks event and I am not aware of a FeedBack mechanism for the speakers other than twitter activity.

Slide Deck

Introduction to Functional Programming with Scheme

View more presentations from Michael Norton.

Code Samples
Thank you to everyone who gave me permission to use their code samples in my presentation.

The Kata in the presentation is a variation on Roy Osherove's String Calculator Kata.

You can find the Scheme Kata results presented in the slide deck on my github.

Scheme Implementation Links

MIT Scheme Page (Download/Installation Instructions)
Dr. Scheme (aka PLT Scheme)
UCB Scheme
Guile (GNU's Embeddable Scheme)

Development Environment Setup

Overview of various Emacs Scheme implementations

SICP Course Materials
SICP Course Page
MIT Tutor (for problem sets listed in MIT Opencourseware 6.001)

SICP Book Info

First videos of the SICP replacement course at MIT via @mfeathers

SICP in HTML

SICP in PDF (direct to pdf link)
Another version with different formatting (direct PDF link)
Yet another PDF version with much nicer typesetting (not direct PDF link. courtesy Kevin Taylor)

SICP in MOBI (Reflowable / resizable for the little Kindle)

SICP Lectures
SICP Lecture Videos (alternate source)
SICP In Other Languages

UC Berkeley's Lecture Series on SICP on ITunesU (requires ITunes on Windows or Mac)

SICP SolutionsHere are some links to some (incomplete) SICP solutions.

http://wiki.drewhess.com/wiki/Category:SICP_solutions

http://www.kendyck.com/solutions-to-sicp/

http://community.schemewiki.org/?SICP-Solutions

http://sicp.org.ua/sicp

One persons detailed journey through SICP

Additional Scheme Resources

Simply Scheme: Introducing Computer Science
Practical Common Lisp
How to Design Programs
More: Systems Programming with PLT Scheme
Teach Yourself Scheme in Fixnum Days
Guide: PLT Scheme
Lecture 11: Introduction to Functional Programming and Scheme
Scheme Materails - NU PLT
An Introduction to Scheme and its Implementation - Table of Contents
Programming and Meta Programming in Scheme
Scheme lectures, mostly « programming musings
Scheme (programming language) - Wikipedia, the free encyclopedia

CodeMash 2010 Review

2010-01-17T16:46:00.000-05:00

CodeMash 2.0.1.0 was a genuine success.

Complaints
There were a couple of issues with the communication of session schedules and the WiFi was problematic. But the event coordinators made sure the schedule updates were communicated quickly through the API, allowing the mobile apps we were all using to inform us of the changes. And the Kalahari resort tried to give us the best WiFi experience they could by segmenting us off on our own subnet and providing us a separate pipe from the rest of the resort guests. Hopefully they will be more prepared next year. I suspect attendance will continue to increase. If they can't support the bandwidth demand, the event may need to consider another venue. One final complaint - AT&T coverage was spotty at best, but if you have used AT&T and travelled even the slightest, you know this is common-place.

Accolades
The rest of the event was fantastic. There were a number of great sessions covering a broad range of topics. Joe O'Brien did a great session on Refactoring the Programmer, Jim Weirich gave a good presentation on a fictitious source management system that had a great deal in common with git, and Chris Smith's talk on F# was downright hilarious. These are a mere few of the many excellent sessions available this year.

The Open Space, run my Steven "Doc" List was also very successful. I personally participated in a good discussion on TDD/BDD with Functional Languages which lead to a new movement to create the Ruby Koans for F#, Scala, Clojure, Scheme, etc.

Dollar for dollar, this is the best conference I've experienced. I sincerely recommend this one to anybody interested in software development; beginner, intermediate, or advanced.

What if no one reads it?

2010-01-02T11:31:00.002-05:00

You should favor readability

Among the books I am currently making my way through is "Exploring Computer Science with Scheme" by Oliver Grillmeyer. The publish date on this particular book is 1998. No matter how often it happens, I feel a twinge of despair for our profession when I read sound advice from a decade or more ago that has yet to be widely adopted; or worse is still hotly contested.

Grillmeyer contrasts a couple different functions that accomplish the same end. One terse, but obfuscated; One verbose, but transparent. In conclusion, Grillmeyer states, "In a tradeoff between readability and length of code, you should favor readability."

Damn straight.

Sure, you can use some Ruby-fu and get those four lines in the controller down to one. Yes, you can in-line the whole damn method call. But to what end? For what purpose? Why are you reducing the lines of code? What is your objective?

Favoring line count

I once completed the Bowling Kata in Ruby. It was approximately twenty five lines of code. It was readable. Each method had a clear and singular intent. I asked a non-developer friend to look at it and tell me what it did. It took him no more than 60 seconds to figure it out. I then told a Ruby developer about the Kata and without even looking at the code he said, "You should be able to do that in seven lines of Ruby."

So I set out to refactor the code down to seven lines. And it was an interesting exercise. I managed to get the code down to about twelve lines; I had cut the code in half. But then I stopped. The intent was no longer clear. One had to interpret the code in order to discern what was happening. My tests were a mess; I could not test behaviors in isolation.

I had sacrificed clarity at the altar of line count. And I was ashamed.

A (very brief) twitter discussion

So after reading the line from Grillmeyer, I tweeted it. Moments later, a buddy responded.

What if no one reads it?

Interesting question.

So you're working on a pet project; something that only you will ever work on. No other developer will ever see this code. And you're working on a feature where the desired behavior is so well known and immutable that you too will never, ever, under any circumstances need to change it. And the language and platform are absolutes; they too will never change - no new libraries, no change in any of your dependencies; not even a revision tick. You are certain that no one will read it; not even you.

And you can either write it in a terse manner, or a readable manner (but not both). Which is better?

Good code is efficient. Good code is testable. Good code displays an attention to detail. Good code has singular purpose and lacks duplication. Good code is expressive. Good code is written by developers who care. Good code is pleasing to read. Good Code is Clean Code.

Having worked on a system that manages over one hundred thousand purchases per day, I do not believe there are many situations which absolutely mandate performance at the cost of readability. So while I expect the argument, I believe it to be an outlier at best, if not completely fictional.

Given the definition of good code and the likelihood that what we are working on does not require obfuscated code for performance gains, there is no other possible consideration.

Code must be written for readability. If it is not; it is not good code.

Certainly, one can opt to knowingly write bad code, but I cannot comprehend the motive.

Retrospective 2009

2010-01-01T12:22:00.002-05:00

Look back to learn, not lament

Life is full of moments; some wonderful, some tragic. Sometimes, you can't assess the quality of the moment until long after it has passed. Not until you've had the opportunity to live in the shadow of the moment and realize the true impact.

I have, for many years, believed that our lives are not governed by the events that occur, but by our chosen responses to those events.

Our inability to accurately asses the quality of a moment, whilst simultaneously being required to chose a response that will certainly alter the course of our lives forever is a fearsome proposition. Yet, however fearsome, I choose this belief every day. I choose it over the notion that all is random and I am a mote of dust blowing in the winds of fate; without cause and without choice and without effect. I choose it over the notion that all is predetermined and I am merely following a foreseen path; without choice and without effect.

With this belief, I march forward. Looking back only to learn lessons that better equip me for my next decision. There is no purpose or value to lament the past. The decisions I make right now alter my future course. And as a result, I know that decisions in the past need affect only my past.

2009 Timeline

First Quarter

Working at The Samara Group (subsidiary of Wayne-Dalton)

Parent Company is suffering and is not committed to success of TSG
Work situation is extremely poor; low trust, no autonomy.
Suspect we are being shut down
Feel obliged to my co-workers and employees.
Concerned how "failure" will look to others.

Losing faith in my technical/leadership abilities.
Negligent of personal health

Running very little
Not lifting
Eating habits are poor

Second Quarter

TSG is Closed by Parent Company

Laid off
Self-esteem very low

Decide not to rush into next job
Need to figure out what makes me happy
Pick up side jobs
Focus on Ruby and Development
Start working with LeanDog and Pillar on job in Detroit
Get calls from ThoughtWorks and several others to interview
Join running club and Men's group
Re-building my self-esteem
Personal Health gets attention

Run daily
Lift daily
Eat right

Third Quarter

Start at ThoughtWorks

Planning to stay for six months at most
Discussing emergent opportunities in Cleveland with LeanDog

Move in with my brother Rick

Sleeping on air mattress in his home office

Side Jobs get no attention
Start Scheme Study Group
Personal Health good

Running almost exclusively
Some lifting
Experience mild back pain
Ease up on strict eating habits

Enjoying life, but miss my family

ThoughtWorks pays for flights home and back so I can see family (WOW)

Fourth Quarter

Decide to stay with ThoughtWorks for as long as they'll have me

Like so many things about the company
Feel "at home" for first time in over a decade

Get (much needed) help with side projects
Moved into Corporate Housing
Personal Health Suffering

Back Pain is chronic
Running limited
Lift very infrequently
Eating habits are poor

Starfish for 2010

Do More

Communicate with Family and Friends
Show Appreciation to Others
Active participation in family finances
Work Out - run, yoga, lift
Study / Learn / Teach
Blog Posts
Ruby and fun languages
Eat Well

Do Less

Java
Side Jobs
Consuming Alcohol

Start

Daily Journal
Help Wife with Career
Join 401k at work (saving)

Stop

Working long hours
Worrying about what others think

Continue

Involvement in Technical Community
Building Personal Brand
Working on relationship with Family

My experience at ThoughtWorks (so far)

2009-12-24T11:15:00.000-05:00

I came across a post written by a former ThoughtWorker and was intrigued by what I read. I've long known that two people can enter a small party and have two completely different experiences based on where they focus their attentions. The larger the party, the more likely the experiences will differ. More significant, however, is how the people themselves differ.

Damana talks of the ThoughtWorks I've come to love; A team of intelligent, talented, motivated individuals working together in an environment that encourages diversity, provides rich individual attention, encourages community involvement, and pushes each of us to continue to grow.

Damana also talks of another ThoughtWorks; A team of ego-driven elitists who lack compassion and fundamental social skills. Intellectual bullies who prefer manipulation over trust and who value the client far less then they do the elegant perfection of software.

I believe both ThoughtWorks exist. I know there are ego-driven elitists. I know there are bullies who prefer manipulation over trust. And I know there are those who value the elegant perfection of software over the needs of the client. I've met all of them at ThoughtWorks. I've worked with each of them. But from my vantage-point, these people are in the minority. They certainly do not make up 75% of the people I've worked with; not even 10%.

In terms of changing the world, I know of no other software company who has "Social Responsibility" as a key part of their corporate values and employs an active "Director of Social Engagement". This individual's role is to get TW more involved in world events; to find ways to leverage our skills and strengths to make the world a better place. ThoughtWorkers volunteered their time to work on software that helps distribute aid in third-world countries. ThoughtWorks hosts events such as Pangea Day and is actively involved in other significant events around the world.

ThoughtWorks is, hands down, the best place I've ever worked. We are a diverse crowd. We come from all over the world with wildly different backgrounds and experiences. One should anticipate some tension amidst diversity, but ThoughtWorks is conscientious in their hiring practices and is intolerant of intolerance.

Damana and I spent time at the same party. We had significantly different experiences. And we are both right. For neither of us can articulate the "truth". Each of us can only share our perception; our interpretation.

There is one more thing Damana and I surely agree on:
"If you ever get to work at a company like ThoughtWorks then don't accept another job[...] it will change your life, your career and your soul."

Business Value is not the only reason to adopt Agile

2009-12-07T23:59:00.002-05:00

Agile Rob posted a column a few days ago entitled, "If You Don’t Focus on Business Value, Don’t Adopt Agile." He tweeted it out and after reading it, I replied that I did not entirely agree. Rob asked that I post a comment on his blog. The following is an extended/modified version of that reply.

I read two articles today, "Adopting Agile Isn't The Point", by Mike Cottmeyer and "If You Don’t Focus on Business Value, Don’t Adopt Agile.", by Robert Dempsey. Rob's posting is an expression of agreement with Mike's.

Mike's basic point is that we can lose the sight of our actual goal when we phrase our efforts in terms of task rather than objective. "When we allowed ourselves to define our work in terms of our activities, we risked losing focus on the desired outcome of the project."

He then applies this to Agile adoptions. The goal is not to have a Scrum master or to do TDD. "Those things are the stuff we do to get the desired business outcome."

You can analogously extend this to other areas of your life. I am a runner. I've set a 5k goal time for myself. In order to get there, I've laid out a plan that includes certain tasks on certain days. My goal is not to run 30+ miles per week. My goal is not to do 8 weeks of hill training. My goal is to run the 5k faster than a certain pace. If I need to adjust the tasks, so be it. If I focus on the tasks, I lose sight of the goal. I may very well finish 8 weeks of hill training and find myself injured.

I agree with Mike.

Rob takes this fundamental premise and extends it to say, "If you don't focus on business value, don't adopt agile."

This I do not entirely agree with.

This, to me, is similar to, "If you don't focus on cardio-vascular health, don't take up running." While cardio-vascular health is a significant and worthy objective, it is not the only reason to run. Fortunately, it is a common and beneficial side effect.

I might adopt agile to improve code quality, to deliver in smaller increments, or to improve communication. These are also valuable and worthy objectives. They are likely to add value to the business as a common and beneficial side effect. Just as a goal of a certain time in the 5k can result in improved cardio-vascular health.

The point is that we know our true goals and objectives. That we know why we are performing certain tasks. And that we not confuse the tasks with the desired outcome. This is not the same as saying there is only one true desired outcome.

Adopting agile isn't the point. Business value doesn't have to be either.

Karate Chop Kata in Ruby

2009-10-15T17:51:00.006-04:00

I have to admit, this was a lot more difficult than I originally anticipated. A binary sort seems simple enough. This is 101 stuff, right?

But my first couple of runs resulted in relatively long procedures with a lot of boundary checking. While my specs were passing, the smell of the code was really bothering me.

I found a reference implementation and gave it a run, but discovered that it failed my specs. After a double-check of the specs to confirm I didn't have something messed up, I decided to dump the RI and try it again.

Finally, the pieces fell together and I could see where most of the boundary checking fell out of the method as I changed the sequence of events.

The Code

class Chop
  def self.find(lookFor, lookIn, start_index=nil, end_index=nil)
    start_index ||= 0
    end_index ||= lookIn.length
    middle = (start_index + end_index)/2
    
    return middle if lookFor == lookIn[middle]
    return -1 if ((middle == start_index) || (middle == end_index))
    return find(lookFor, lookIn, start_index, middle) if lookFor < lookIn[middle]
    return find(lookFor, lookIn, middle, end_index) if lookFor > lookIn[middle]
  end
end

The Specs

require "spec"
require "karate_chop"

describe Chop do
  context "with an empty sorted array" do
    it "indicates item not found" do
      Chop.find(1, []).should == -1
    end
  end

  context "with search target not in array" do
    it "indicates item not found" do
      Chop.find(1, [0,2,3]).should == -1
    end
  end

  context "with search target in array" do
    it "provides the index of the located item when in the middle of the array" do
      Chop.find(1, [0,1,2,3]).should == 1
      Chop.find(4, [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21]).should == 4
    end

    it "provides the index of the located item when it is last in the array" do
      Chop.find(20, [5, 10, 15, 20]).should == 3
    end

    it "provides the index of the located item when it is first in the array" do
      Chop.find(20, [20,40,60,80]).should == 0
    end
  end

  context "with a large array" do
    it "locates the item" do
      search_in = Array(0..900)
      Chop.find(100, search_in).should == 100
    end
  end
end

I am looking for feedback on these. Please, feel free to let me know how I could improve my code or specs. Or share links to your own solutions.

Martin Fowler on Technical Debt

2009-10-14T12:13:00.003-04:00

Martin Fowler just posted an article on Technical Debt in which he discusses the Technical Debt Metaphor. Fowler argues that the metaphor should (and does) include messy code. He talks about deliberate and inadvertent debt as well as reckless and prudent debt. Prudent and Deliberate is the most desirable. While Reckless and Inadvertent is the least desirable. He published the following quadrant to help explain his concept.

He concludes with a statement about the risks of using the debt metaphor for messy code; "However a problem with using the debt metaphor for this is that I can't conceive of a parallel with taking on a prudent-inadvertent financial debt. As a result I would think it would be difficult to explain to managers why this debt appeared. My view is this kind of debt is inevitable and thus should be expected. Even the best teams will have debt to deal with as a project goes on - even more reason not to recklessly overload it with crummy code."

I would argue that the worst form of debt under this definition is in fact Reckless and Deliberate. This has been the motivation behind my assertion that Messy Code should not be considered Technical Debt. It allows teams to hide messy code behind a comfortable metaphor. We, as programmers, need to hold our standards high. Our goal needs to be a clean code standard.

While I recognize that Messy Code happens inadvertently, I don't think it should happen deliberately without very clear communication to the customer. And when this conversation takes place, I think you need to say, "In order to meet the deadline, we need to write messy code that will cause us problems from here forth until it is cleaned up." rather than saying, "In order to meet the deadline, we need to take on some technical debt."

Practicing Your Craft Through Code Kata

2009-10-14T08:52:00.000-04:00

I assume most of you are aware of code kata. For those who are not; a kata is a simple code exercise. The idea is to perform these exercises in a practice session with no interruptions and no pressure where you can try each as many times as necessary. The goal is to learn and to build the muscle memory necessary to perform these tasks flawlessly in pressure situations.

I am putting together a series of kata for your consideration. I will be certain to give attribution for each as most (if not all) will be exercises found on that thar InterWeb, written by others and ~~plagiarized~~ highlighted here.

For my first few, I plan to draw from the series available on the Pragmatic Programmer's site where, to date, Prag Dave has listed 21 kata.
For all kata, I will follow a Pomodoro style, using tomatoi.st as my timer. I will attempt to complete each exercise in a single 25 minute pomodoro. Most kata are achievable in this amount of time, but not necessarily on the first attempt.

I will post code snippets and might even get gutsy and put up a few screen casts if I get proficient enough at some of them. It is my intention to complete all kata in Ruby. I may opt to work them in Java, Scheme, C#, or javascript as well.

I welcome your feedback and constructive criticisms. I am looking to improve my craft through kata. If you see something I could be doing more efficiently or effectively, please let me know.

SDTConf Day Two

2009-10-11T20:53:00.002-04:00

Day two started with another quick planning session. This one went a lot faster. We had fewer topics suggested and everyone was more familiar with the format. This allowed the first sessions of the day to get started a bit early. Of course, following the Rules of Open Space, "Whenever it starts is the right time." So I suppose everything started precisely on time.

I started the day with a session on refactoring. This was a good session; well attended and well presented, but I was in the mood for a little more interaction, so I followed the rule of two feet and wandered into a discussion on introducing Agile in a Hostile Environment. Right up my alley. I failed at this numerous times before my first successes, so I had plenty of experience to draw upon. The attendees were primarily developers and leads who were sold on Agile, but found it difficult to introduce into their teams. I could empathize with them. Each of their attempts was met with a lot of resistance.

We discussed approaches that involved avoiding too many buzz words, identifying one likely ally, or simply leading by example. But the best advice had little to do with Agile and more to do with simple human nature. Listen to your team. Get to understand their personal pain. And then help them relieve that pain. While you may genuinely believe that TDD will solve a lot of problems for the team, if their immediate pain is with the build, then get CI stood up first. People are usually far less resistant to change than we give them credit for. The problem is often that they are already uncomfortable. Sweeping change is too big, too vague, and too risky.

I do have another piece of advice for those we are struggling in environments that are highly resistant to change. Leave. Sometimes it is better to change the people you are around rather than try to change the people around you. I am not suggesting we all quit at the first sign of resistance. But sometimes there comes a point when one realizes they are merely tilting at windmills.

My next session was on User Experience and User Centered Design (UX/UCD) in an Agile environment. My objective for the discussion was to find practices that served UX/UCD well and mapped to iterations. The predominant thinking is that UX/UCD is an up-front activity that must be complete prior to development. I'd like us to continue to challenge that thinking.

A great deal of the early discussion was around Contextual Inquiry as a part of requirements gathering and User Testing during the development cycle. We shared stories of success, stories of near success, and stories of sheer frustration. But we struggled to come up with additional techniques or insights. I was enjoying the discussion, but felt the session was coming to an early end. We were covering the same ground with no new insight.

And then Jeff Patton spoke. Quiet. Unassuming. Jeff stated that there are essentially three facets to the user experience. He drew a pyramid and separated it into three horizontal sections. At the base, he wrote "Utility" and explained that this is what the system does. Contextual Inquiry helps us define this. In the center section, he wrote the word "Usability" and explained that this is how the system is used. User interviews help us define this. Finally, at the top he wrote "Aesthetics" and explained this is presentation. It is important to understand the practices and how and where they apply.

You need to have Utility covered first. This does not make it the most important, but if the application cannot perform the intended function, it is a failure. It does not matter how usable or pleasing it is.

You need to have usability covered next. If an application is capable of performing the task, but is difficult to use, you will have less success. If users have alternatives, you risk losing them to something easier to use. If your users are a captive audience, you will see increased costs in training and re-work or they will do everything they can to avoid using the software.

Finally, you need aesthetics. This is where the psychological aspect is most significant. If people are pleased with the interface, they may actually tolerate a lack of usability. Jeff used Apple as an example. Design (aesthetics) are very important at Apple. While their products are not always easier to use, you do not mind the minor inconvenience. You are pleased to use the iPhone. It is ok that you have to scroll over three pages to find the app. The WAY you scroll the pages is kinda fun.

There are plenty of applications that prove Utility and Usability are sufficient. Craig's List is so anti-aesthetically conscious, it seems the lack of design IS the design. People don't care that it is plain; it does exactly what they want and it is easy to use.

Jeff's points resonated with me. I knew these things, yet failed to consider them as I was looking for techniques that could be mapped to iterations. If you don't understand how the practice applies and why you're doing it then it doesn't much matter if you do it before, after, or during an iteration. You're probably going to get it wrong. Figure out what you're trying to achieve, then figure out how.

I really enjoy conferences like these. Low ceremony, high value.

There are three ways to learn; push, pull, and share.

Push is where you sit in a class or session and someone walks you through a lesson or seminar. This is typically low signal to noise. You are going to get a lot of information, only some of which you are currently interested in or can use.

Pull is where you seek out the data and gather it for yourself. This is better signal to noise. You can control the flow of information and can target the information to your specific interest or need.

Share is where two or more people freely exchange ideas. This is my favorite form of learning. Everyone learns and if the conversation is truly a balanced and free exchange, there is all signal and no noise.

SDTConf and other open spaces are Share learning.

SDTConf Day One

2009-10-11T10:22:00.002-04:00

I really like the open space format. Simple rules. Maximum value.

Whoever shows up is the right group of people.
Whatever happens is the only thing that could have.
Whenever it starts is the right time.
When It is over, it is over.

We started the day with a round of introductions and then did a light-weight scheduling exercise to get the sessions for the day arranged. I was so enthralled with the other potential topics, that I pushed UX/UCD and how they map to Agile to on-deck for day two. I hope I don't regret that decision. Some folks are here for the one day.

The rule of two feet is a beautiful thing. This is not an explicit open space rule, but it certainly exists. The rule of two feet simply rephrased is, "You have two feet. If the session does not serve you, walk." It is not considered rude to leave a session in progress. To some extent, this is encouraged. It is considered rude to break wind and yell, "F you guys, I'm outta here!" I learned that the hard way.

I attended a number of excellent sessions today and participated in several very good hallway discussions as well.

We discussed the pros and cons of taking advantage of "others' code"; from frameworks to libraries to gems to simple copy/paste. We shared stories of pain and stories of success. In the end the general consensus was that frameworks are usually painful where libraries and more discrete items are easier to leverage with minimal risk. Ultimately, we agreed that the more discrete the component, the better the API, and the greater the intent of reuse, the more likely you are to be successful.

We evaluated roles and the sequence of steps in the overall development cycle. One conclusion drawn was that all involved in the delivery of software should be called developers. You may (or may not) have roles such as BA, programmer, and QA. But ALL of them are responsible for the successful development of code. There was lengthy discussion around the stages of development and while we all agreed that putting creation of tests in front of development of code, we also agreed that it is a complex cultural shift and will take time. We're not talking about just unit tests here. Acceptance tests; the specific criteria by which the story will be evaluated need to happen before code is written.

We discussed learning and the intimidating amount of knowledge a developer really needs to have in order to be a master in their domain. Hell , the intimidating amount of knowledge a developer really need to have in order to be a novice in their domain. How do we create a path to guide new developers? Are there a simple set of one dozen patterns, practices, and/or principles that every new developer should learn first? Is there a single pattern or principle (there can be only ONE) from which all others can be derived? It was a very good conversation and I look forward to the results of the discussion.

Dinner conversation was as interesting and educational as the conference discussions. At my end of the table, we discussed (among several topics), the long-term value of XP practices in a mature shop. Do highly skilled and experienced developers need to follow these practices or do they have enough experience that they no longer need the safety and guidance provided? Do these practices actually impede delivery once you've achieved a certain level of skill and proficiency?

While it was an interesting conversation, it concerned me, much like Spolsky's Duct Tape Programmer post. Let's assume the assertion is true. Developers reach a level of excellence where they no longer need to follow some of the practices that got them there. Here's my primary concern - How do you honestly know you are so good, you no longer need the safety net for performance? Our profession is riddled with a strong ignorance to ego cohesion. I hear story after story of developer who was absolutely certain they were awesome and correct in everything they did and they then stumbled (or were dragged kicking and screaming) into TDD and had an "aha" moment. Prior to the "aha" moment, the developer knew they were excellent and did not need those West Coast, touchy feely, hippie, group hug concepts¹. There are far too many developers who are prior to their own "aha" moment. They may read the Duct Tape post or get involved in these conversations and conclude that they are one of those excellent developers who need not concern themselves with the "overhead" necessary only for lesser mortals.

I am looking forward to day two. It is a fantastic experience to spend time with professionals interested in their craft; those who see value in taking a weekend and spending time (and some money) on developing a deeper understanding and challenging their own current views.

1 - Special thanks to TB for this expressive description of Agile. I suspect TB is still sitting alone in his cubicle somewhere cranking out amazingly complex modules full of features nobody asked for, but he is absolutely confident they will need someday.

Craftsmanship

2009-10-07T18:39:00.008-04:00

I have the profound and intimidating honor of being the fifth person to make note in the Wandering Book. To be honest, I'd hoped to be later in line. I'd hoped I could read numerous entries and ponder all the wisdom before it came my turn to write. As the fifth, I have to admit there is already a great deal of wisdom in the book. The four before me are remarkable people. And those who will follow me are surely remarkable as well.

Corey Haines talks about practice and learning. He talks about the path to mastery and ultimately, the role of the master as teacher.

Jason Gorman explains that Craftsmanship is not about practices or membership. It is about caring, learning, and practicing.

Dave Hoover ties the two prior entries together and stresses the need for more people to commit themselves to mastery.

Eric Smith tells a personal story of how the craftsmanship movement rekindled his passion for software development.

I've pondered these stories; these lessons; these words of wisdom. I've thought about my own journey. I've considered what it is that drives me. What it is that inspires me. Why I choose to be a software developer and what is important to me about my craft.

There is a simple, poignant, common thread throughout the book already. Learning, Practicing, and Sharing. Craftsmanship is about continual improvement. Craftsmanship is about applying the craft. Craftsmanship is about being your best and helping others to be their best. Craftsmanship is about the free exchange of ideas.

My journey has been long. I've been in the industry for over 20 years now. And I feel as though I am only at the beginning. But throughout the years, the most rewarding experiences have always been those where I worked closely with an open and honest team. And consistently, it is from those experiences that I learned the most and was able to share the most knowledge with others.

Craftsmanship is Learning, Practicing, and Sharing.

Running Developers Unite! - Update

2009-10-01T08:32:00.001-04:00

I received a lot of positive response from the initial posts about getting a running group for developers started. After a bit of research, it seemed the fastest way to get something going, was to take advantage of www.dailymile.com and start a group.

I started the group about one week ago and we have 9 members so far. If you are interested, please visit the group and join us. There is no obligation. It's just a bunch of developer-types who also happen to run, whether it be casual, for fitness, or competitive.

http://www.dailymile.com/groups/595-test-code-run

I'd rather be in last place

2009-09-25T20:45:00.002-04:00

I joined the cross country team my freshman year of high school. I knew nothing about the team and little about the sport, but I figured running wasn't too difficult and was certainly less dangerous than football.

It turns out the team was one of the best in the state. They had a legacy of excellence for well over a decade. They consistently won their league, placed in districts and regionals and sent at least individuals, if not the entire team to state.

These guys were good. And I was terrible; slow, gangly, poor form, clumsy.... I had limited natural talent for running (or sports in general it would seem).

I was determined to get better. I was determined to letter my freshman year. So I hung out with the junior varsity and varsity whenever I could. I would run with them for as long as I could endure before falling off the pace. I got obliterated every day in practice and I finished "last."

Some of my team mates made fun of me. "Norton, why do you run with those guys? You finish last every day. Run with us. Don't be a moron."

But I lettered as a freshman. I went on to do fairly well. I lettered all four years. I ran varsity for a couple of years and rounded out my senior year as team captain.

I am much older now. And I still run. And I still remember the lessons from my freshman year.

Software isn't a competition. But like cross country, it is an individual task executed as a team. And the entire team relies on each individual; from the top runner to the seventh. On any given day, one team member's performance can suffer and it is up to the rest of the team to make up the difference.

If you want to improve, surround yourself with people who are better than you. Push yourself every day to meet their mark. And if you finish last, come back the next day and try again.

I'd rather be in last place among the lead pack than first place among the second-string.

Running Developers Unite!

2009-09-25T15:07:00.002-04:00

Update:
I started a group on Daily Mile. Make sure to sign up!

This is a quick post to get things started. I will get a more formal site up and running in due time.

There are a lot of developers out there who run, have recently taken up running, or are thinking about it.

I thought it would be cool to get a group of running geeks together. Nothing too formal, just a "club" for us running developers. We can get events together like Chad Fowler's RuyConf 5k. We can share stories. And we can help to keep each other motivated and informed.

I am currently looking for a fitting name for the club.

Leave a comment indicating your interest. If you have name suggestions, include them in the comment.

Alternatively, you can send a message to michael [at] docondev.com with "Running Developer" in the title.

Messy Code is not Technical Debt

2009-08-31T21:09:00.012-04:00

Technical Debt is a common topic these days. How is it incurred? How should we track it? When should we pay it down?

It is a metaphor commonly understood. Our customers get it. While they may not like it, they do understand. Technical Debt is incurred today and needs to be paid down; preferably sooner rather than later what with compound interest and all that.

Technical Debt is accepted by many as a natural part of the development process. Frankly, I agree. I think Technical Debt is a good thing to take on for short periods of time. Perhaps it is even unavoidable in some cases. Therefor we should expect it and deal with it accordingly.

But there is something insidious going on here. In many cases, perhaps even most cases, what developers are really talking about is code that is not Clean.

And Messy Code is not Technical Debt.

What is Technical Debt?

Ward Cunningham coined the phrase Technical Debt.

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise."

Misunderstandings about Technical Debt

Ward's original description was vague. His clarification which later followed may have come too late. Many had already taken the phrase and added their own flavor to it. Martin Fowler discusses Technical Debt and even refers to Ward's definitions, but then goes on to say "doing things the quick and dirty way sets us up with technical debt". Jeff Atwood also allows the phrase "quick and dirty" to creep into his explanation of Technical Debt. And in an Intel posting, the definition is expanded to:

"Technical Debt is loosely defined as the volume of poorly written lines of code, poorly refactored, not following coding standards, not supported with sufficient unit tests, and the amount of code duplication."

This seems to be the common definition of Technical Debt today. And it is most unfortunate.

Messes are not Technical Debt

Poorly written code, lack of standards, lack of tests, code duplication, multiple responsibility, complex interfaces, large classes, poor/insufficient error handling, and opaque intent are all messes. Not a one of them is Technical Debt. And as such, none of them should be categorized as Technical Debt. For a comprehensive listing of messes, see Robert Martin's Clean Code.

Messes Preclude Technical Debt

Technical Debt is paid back through refactoring as our understanding of the domain matures. "The ability to pay back debt [...] depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem."

Clean Code is actually a prerequisite for Technical Debt. If you don't have Clean Code, you cannot expect to pay the debt back. If you have a mess, you cannot reasonably incur Technical Debt. In fact, you are not incurring debt, you are merely adding to the existing mess.

Messes are not Acceptable

Uncle Bob has stated, "There aren't any reasons to make a mess."

I don't entirely agree with Bob on his point. I think there aren't any reasons to leave a mess. TDD encourages us to take tiny steps. Some of these steps result in small messes. Messes that we will clean up in very short order. But we've made a mess nonetheless. And there is no shame in having done so. To leave the mess for any significant period of time or to allow more mess to accumulate is, however, unacceptable.

Stop calling messy code "Technical Debt"

Stop hiding behind the term Technical Debt. If you have messy code, clean it up. Implement the Boy Scout Rule and get it taken care of.

Most important - don't treat the permeation of mess into your system as something natural and acceptable.

Create a Culture of Integrity

2009-08-28T23:07:00.004-04:00

My friend Patrick Wilson-Welsh once asked me if I knew the key distinction between Accountability and Integrity. I said I did, but then found myself struggling for an answer.

Today, I think I get it. Perhaps I should check with Patrick.

Accountability and Integrity

Accountability

Accountability is enforced externally; it is a requirement or expectation to justify actions and decisions. A person can be accountable to or accountable for, but cannot be simply accountable. Accountability requires another party.

Integrity

Integrity is enforced from within; it is a quality of honesty and morality. It exists regardless of accountability. A person has integrity (or does not). Integrity does not require another party.

A key difference

Accountability is flawed. There are numerous issues, from the "it's not wrong if I don't get caught" mentality to the "that is how the boss wants it done" escape clause. Accountability can be unreliable. If expectations are not clear, if the boss is away, if people feel dis-empowered (which is likely), or if people "suck up" to the boss, the outcome may not be what is desired or expected. As a result, morale can deteriorate and lead to more issues. Ultimately, accountability of subordinate to superior creates an environment of distrust and dysfunction; this cannot scale.

Integrity does not require external enforcement. Integrity does not have escape clauses. Integrity is consistent. Integrity cannot be "sucked up" to. Integrity is reliable. And integrity scales.

Some will argue that integrity is adherence to a moral and ethical standard, but is independent of the nature of that standard. This is true. Integrity in not synonymous with morality, rather it is one's ability to be true to their own morality. This makes integrity no less desirable.

Creating a culture of integrity

So how do we create a culture of integrity?

Have integrity

Leadership sets the tone. Hypocrisy will not beget integrity. If you make promises, but don't keep them; If you expect full disclosure, but hold back data; If you promote autonomy, but punish "mistakes"; If you preach teamwork, but practice espionage; you had best expect to be surrounded by people adept at surviving in such an environment.

Hire better

It is quite likely you are hiring based on the wrong criterion. Typically, candidates are first filtered based on credentials and experience. Do they have the requisite degree/certification? Have they used our target tools for the requisite length of time? Then, they are interviewed to certify the proclaimed credentials and experience. Finally, in more progressive environments, the preferred candidate meets the team to make sure there is good chemistry; a quick check to ensure nobody resorts to fisticuffs.

Invert the selection process. Don't hire based on experience and credentials. Hire based on aptitude and attitude. Aptitude - can they learn what you need them to know? Attitude - are they a fit for your team and your company? Put the time and effort into making sure the candidate is capable of learning, willing to learn, and has values that fit for your organization. If they have the pedigree too - Hey, that's swell.

Why invert the process? Smart people easily learn new skills. Selfish people don't easily develop empathy.

Communicate expectations

Produce a values statement. Publish it. Share it. Use it in the selection process.

Develop a code of conduct. What is expected of employees in and out of work? Keep it general. Trust your employees to apply the guidelines rather than providing a tome of situational requirements.

Model specific behavior

We've covered that you should have integrity, which is paramount. Modeling the specifically desired behaviors reinforces the expectations and encourages voluntary adherence. If team members perceive a lack of integrity in leadership or among their peers, they are less likely to exhibit integrity themselves. This is not to say they will lack integrity, but they may not openly show it. An environment of deception encourages the righteous to be cautious.

Integrity Endures

Accountability works, but it is ultimately the coercion of good behavior through fear of repercussion, no matter how gentle. If you want success that endures; create a culture of integrity.

Keep Retrospectives Fresh

2009-08-28T15:32:00.008-04:00

Retrospectives are an important (and frequently poorly done) practice. They provide an opportunity for discussion, learning, and adaptation. Without retrospectives, a team is likely to fall into a soothing rhythm and fail to recognize early the need for change.

But retrospectives themselves can become common and numbing. The same moderator, the same three questions, in the same room, at the same time .... (yawn).

Here are a few tips on keeping your retrospectives fresh.

Change Venues and Schedule
Hold iterations in different rooms. Move them to the afternoon before or the morning after their regularly scheduled time. You'll get a different energy and perhaps a different perspective.

Change Moderators
Not only can changing the moderator change the pace and style of the discussion, but it can change the way people communicate. Allow each team member who is interested the opportunity to moderate retrospectives.

Change Styles
We're all familiar with the standard three-question, moderator as scribe format for retrospectives. Mix it up. Use the starfish or circle of questions. Have people write their own suggestions on index cards, have a third-party collect them and write them on the board. Find new ways of soliciting input and you will get new input.

Change Focus
Hold retrospectives with a broader focus. Rather than discussing the last iteration and the next iteration, discuss the last several weeks or months and the next few months. Allow the team to not only discuss the tactical, but the strategic. With a new focus comes new perspective and new insight.

Retrospectives are about learning and adapting. They are critical to the long-term success of an Agile team. If you're not doing them; start now. If you are, make sure you keep them fresh to get maximum value from them.

Visible Metrics with Corey Haines

2009-06-26T17:21:00.003-04:00

We've been discussing Metrics in the Software Craftsmanship Group and I just posted some notes on the topic yesterday. Today, I had an opportunity to watch Corey's "Road Thoughts" on Visible Metrics.

Road Thoughts - Visible Metrics from Corey Haines on Vimeo.

And I like where Corey is headed with this. The measurements discussed are related to code quality. They apply to a code base written by one or by a team of hundreds. These metrics can and should be used for good. Developers can monitor their improvement or ensure their quality does not slide.

Corey takes this concept to a new level; comparative metrics. Metrics that are gathered about your code base, but are devoid of any specific intellectual property. These metrics are then shared, perhaps publicly or perhaps anonymously, for collective comparison. So not only can you then monitor your own quality, but you can compare against others. How do you mark against the industry as a whole? How do you mark against companies of similar size in your regional location? How do you compare against individuals around the world in your language of choice?

With courage, what can we as a community do to help each other learn and grow?

Metrics in Software Development

2009-06-25T20:43:00.006-04:00

Today I posted an entry on the Google Software Craftsmanship Board. In the posting, I asked if anyone had experience with individual velocity metrics on an Agile project. I posted a similar (but more brief) inquiry on Twitter as well.

The responses were varied and the discussion was good. But I was a bit surprised by the overall quality of the responses.

First of all, I had to rephrase the question more than once before anyone answered it. I received many vague and prescriptive responses stating it should not be done. But most folks never indicated if they had personal experience with it. "That's not the agile way" seemed to be a satisfactory argument. No additional support required.

Only one respondent directly stated they had experience with using individual velocity metrics. They also described a disastrous outcome; a complete breakdown of trust, quality, and throughput. All of which, were attributed to the collection of a single data point. Seems to me a project that crashes and burns that hard has issues beyond collection of a metric. Perhaps the collection (or use) of the metric was an indicator of a greater problem, but I doubt it was THE problem. In other words, the team was likely to suffer the same fate whether or not personal velocity data was gathered. More likely, the motivation behind the collection and use of the data was the real issue.

As the discussion progressed, there seemed to be a dangerous general consensus; metrics that apply to individuals are bad and metrics that apply to groups are good. While the discussion started with velocity, it took a winding path through all forms of data points; code coverage, cyclomatic complexity, estimation accuracy, etc. The danger here is the generalization of good and bad based on individual or group respectively.

Good points were also made. Many spoke of the need to understand the purpose of the metric. As one individual put it:

(1) you need to be aware of what question you are asking and what situation you are trying to change;
(2) you need to understand what the relationship between a given metric and a given property is;
(3) you need to [be] clear under what circumstances the metric will cease to be relevant.

Anthony Broad-Crawford said it very well:

As a manager myself the primary goal of metrics is to simply create a "check engine light". Meaning, when the light comes on, it doesn't necessarily mean anything is wrong. What it means, is you should "pop open the hood" and start asking some questions to figure out if something really is in fact wrong. For example, if you did track individual velocity metrics, and someone did report a very low number for the iteration, a check engine light should come on. It doesn't mean the developer did anything wrong or sub-par. It could be for any number of good things (pair programming, design sessions, training, etc). However, if a goose egg is thrown, and they didn't participate in anything that would account for the goose egg (extensive pairing, design sessions, training, etc) something may be wrong and you as the manager should find out.

I do agree if management simply looks at the spreadsheet and makes assumptions (good or bad) based on some threshold it will be problematic. Metrics, must like everything else, are not black and white. A good manager (IMO) will realize that metrics are shades of gray and act accordingly.

The discussion was primarily about the need for individual velocity metrics. And the general consensus (on Google and on twitter) was that individual metrics are bad while group metrics are good.

But metrics, whether individual or collective, can be used for good or evil. They can result in improved or hindered performance. They can tell a valuable story or they can completely mislead.

To categorically dismiss all metrics related to individuals is almost as dangerous as categorically accepting all metrics that apply to groups.

We need to recognize that metrics without a clear and expressed purpose are noise at best and are quite likely dangerous. And the metrics are merely indicators; they don't tell the complete story. I like the "check engine light" analogy. Metrics let you know that you need to look into it further.

Altering your Session Key in Rails 2.3

2009-05-25T09:28:00.006-04:00

I am working on a 'toy' application that I started a couple of Rails releases ago. When I ran my test suite, I received the following warning:

DEPRECATION WARNING: Disabling sessions for a single controller has been deprecated. Sessions are now lazy loaded. So if you don't access them, consider them off. You can still modify the session cookie options with request.session_options.. (called from /Users/docondev/[...]/app/controllers/application_controller.rb:9)

The line in question follows:
session :session_key => '_docondev_session_id'

I learned this technique from several RoR books written only a couple of years ago, but there is a better way to alter the session key.

Although I could have altered the line in application_controller.rb, I decided to put the settings in a more appropriate location. I removed the line from the application-controller entirely. I then altered the config/initializers/session_store.rb file.

The changes should be fairly obvious, but note that :session_key and been changed to :key. I alter the secret by replacing the end of the string with my application name. This is really not necessary, but it is a habit I've established, it does no harm, and it keeps my key and secret visually coupled.

ActionController::Base.session = {
:key => '_docondev_store_session',
:secret => '005000374cbcd1[...]docondev'
}

I disagree with Uncle Bob on this one

2009-04-15T19:38:00.003-04:00

I am reading Bob Martin's "Clean Code - A handbook of Agile Software Craftsmanship" again. For the most part, I am really digging it. It reminds me a bit of Steve McConnell's Code Complete. I still have the original version of McConnell's book around here somewhere. But I digress (and show my age).

In Chapter 9, Martin covers unit tests. In listings 9-3 and 9-4, Martin shows the "simplification" of a unit test. Listing 9-3 makes two method calls followed by five assertions. Each assertion checks a specific state. Each state is clearly identified. I do not particularly like the five assertions. But this is not the point that Bob makes. This is not the correction he covers. Instead, he condenses all five assertions into a single assertion by introducing a string of seemingly arbitrary characters.

We go from:

assertTrue(hw.heaterState());
assertTrue(hw.blowerState());
assertFalse(hw.coolerState());
assertFalse(hw.hiTempAlarm());
assertTrue(hw.loTempAlarm());

To:

assertEquals("HBchL", hw.getState());

He goes on to explain that each character in our string represents a possible state; Capital is true, Lower is false. He follows up with, "Notice, once you know the meaning, your eyes glide across that string and you can quickly interpret the results. Reading the test becomes almost a pleasure."

WHAT?

"Once you know the meaning"? This is not from a solution domain. This is not from the problem domain. This removes clarity under the guise of improved readability. How, pray tell, am I to know the meaning? Is there a comment in the code to explain the meaning? Is he really suggesting that a blatant code smell is better than methods that clearly indicate the intended behavior? And what happens when getState needs to also return the humidifier State? How much code breaks? I should be able to introduce a new behavior without these issues.

I have to disagree with Uncle Bob on this one. This is NOT a better solution. It does NOT make the code more readable. I am suprised to see this recommendation and I bet it does not appear in the Second Edition.

Break each assertion out into their own test within the class, put them all into their own test class with a shared setup and tear-down, or use a Template Method pattern. Frankly, you could just leave them all in a single test given they all test the same single concept. But this string of place-holders with case representing on or off state is a fart in a garden of beautiful code. It just smells bad.

Ruby on Rails - Basic Authentication

2009-04-11T18:36:00.003-04:00

In this post, we are going to cover a very simple way to implement authentication in your application. This is not an appropriate technique for securing a commercial application in production. I use this technique to quickly "secure" an application while in User Acceptance. It allows me to put the application out on the internet and give it a single user name and password. This technique can also be used for easy REST authentication.

Let's assume your intention is to secure the entire application. Add the following to your application controller:


class AdminController < ApplicationController
 before_filter :authenticate

private
 def authenticate
   authenticate_or_request_with_http_basic do |username, password|
     username == 'UserName' && password == 'SecretPassword'
   end
 end
end

This will "secure" the entire application under a single account.

If you prefer not to put the plain-text password in the source, you can instead use the following:


require 'digest'

class AdminController < ApplicationController
 before_filter :authenticate

private
 def authenticate
   authenticate_or_request_with_http_basic do |username, password|
     encrypted_password = Digest::MD5.hexdigest(password)
     username == 'UserName' && encrypted_password == '58d613129c5e71de57ee3f44c5ce16bc'
   end
 end
end

I used http://www.miraclesalad.com/webtools/md5.php to generate the hash

10x Difference in Software Developers

2009-04-09T15:23:00.004-04:00

I finished reading Uncle Bob's posting on Master Craftsman Teams and in the comments was a link to Steve McConnell on 10x differences in software developers.

I encourage you to read both articles along with the comments attached to each.

In McConnell's article was a paragraph that made me stop and think for a bit:

"Another factor is that, while numerous studies have found 10x differences among individuals, researchers have not found 10-fold differences among programmers working within the same organizations. Some research has found that good programmers tend to cluster within certain companies, average programmers tend to cluster within other companies, and so on (Mills 1983). So even if there’s a 10x difference industrywide, the difference you’d typically see within a given company is more like 3-5x from best to worst, which means the difference from best to average is more like 1.5x or 2x within any given company."

So which company am I in and with whom have I clustered? What about you?

I can say with certainty that I've spent some time at the bottom of the scale. Rallying against not only the organization as a whole, but against the fear and apathy of my own team. Clustered they had. And they settled in an environment that supported them. I posit to you - should you ever find yourself in this situation, it is far easier to change your circumstance that it is to change an organization. I should have left far sooner than I did.

Today, I find myself surrounded by wonderful, talented, people. I suspect I pull down the multiplier, but I aspire to be one of them. And the best way I know to improve yourself is to surround yourself with people who are much better than you. People who can push you, challenge you, and teach you. It worked for me as a musician. It worked for me as a runner. I am certain it will work for me as a software developer.

Look around. What end of the multiplier do you think you are on in your current organization? And are you clustered with the top, middle, or bottom of the scale?

Is that where you want to be...?

Values

2009-03-20T18:05:00.002-04:00

Our Values...
... are the foundation for all decisions. They serve as the compass that guides us through our personal and professional lives. All action; all thought; in every way we represent ourselves; we must represent our values.

Be fair.
Find the answer that best serves all parties. Act upon your highest sense of right.

Improve.
Grow continuously, personally and professionally, in small ways. Evolution is the sum of many tiny, nearly indiscernible adjustments.

Innovate.
Seek new ways; seek new means; do the unexpected.

Take Initiative.
Present your ideas. Put forth the extra effort. The one who make the most mistakes, learns the most lessons.

Be accountable.
Answer for your mistakes and your deserved praise will come.

Be forgiving.
Seek to understand and assist. Do not condemn others for their differences. To criticize and dismiss leaves neither party better off.

Participate.
Become truly involved. Make this your team, for it already is.

Have respect.
Honor your coworkers and clients.

Live.
Make your life rich in many ways. Seek new experiences, new relationships, and a new perspective. Then bring it back and teach others.

And always, Tell The Truth.

- Michael J. Norton (1997)

Code Retreat #2

2009-03-15T09:51:00.012-04:00

Yesterday was the second Code Retreat. Thanks to LeanDog for the use of their facilities. We didn't quite hit 40 in attendance, but we came close. With participants like Chris Judd, James Shingler, Corey Haines and J.B. Rainsberger, we had some real ninjas present. I had the fortune to pair with Corey and J.B. as well as several others. All of the pairing experiences were fantastic. I learned something new with each iteration of the kata. I couldn't have asked for more.

The format was pretty simple. We paired (or tripled) for 40 minutes with 10 minute breaks. Using TDD and ping-pong or carousel, we attempted to create a program for Conway's Game of Life. At the end of each 40 minute session, we threw away the code, changed partners, and started all over again.

For many, this sounds like an exercise in torture. It is nearly impossible to write a solution for Conway's Game of Life in under 40 minutes. So how did we expect to achieve anything for the day?

I came to genuinely understand the purpose of the day early into the second round. I was in a triple the first round and we'd made it pretty far. We were satisfied with our approach and were confident we were on the right track. One of our members swapped out, so I was in a pair with a gentleman I had already completed a round with. Dumping the code was painful. All that progress lost. We decided to quickly rebuild what we'd previously developed and move forward with our solution. While he was writing a test, Corey Haines joined our team. I was explaining our approach to Corey. He remarked how different it was from the approach his prior team had taken. We were coding as we spoke. Before we knew it, we'd taken yet another approach to the problem. One neither of us had previously considered.

This was the purpose of the day. We weren't there to use Java. We weren't there to practice a few agile techniques. We certainly weren't there to write the Game of Life. We were there to sharpen the saw. To share. To learn. To grow. This was everything about the journey and nothing about the destination.

There was no right approach. There was no wrong approach. There was only approach. Working together, sharing ideas, joking, and honing our skills.

You may not be comfortable with Java (or Ruby or C# or ... ). You may not know much about TDD. You may have never paired before. None of these things matter. If you are a professional developer who understands that what you do transcends a language or tool set, then Code Retreat is certainly for you. Wether you are new to the profession or have 30+ years of code behind you, there is something to be gained from sharing with others.

If you knew about this one and didn't make it, you missed a fantastic moment. Be sure to make the next one.

Installing git on a Mac

2009-03-08T10:11:00.007-04:00

I've seen a lot of posts on bulletin boards and other sites regarding the install of git on a Mac. It appears many people have tried to download the source and compile it only to discover missing dependencies and other annoying issues.

I did the following and was up and running in 5 minutes.

Install MacPorts
If you have MacPorts installed, you just need to update it.

The full details for installation of MacPorts are available on their site.

http://www.macports.org/install.php

Confirm Latest Update of MacPorts
sudo port selfupdate

Install git
sudo port install git-core [+svn]
Use the optional +svn parameter if you will want to import from svn

The git install may take some time. There are a number of dependencies that need to be installed as well, but MacPorts takes care of it all for you.

That's it.