To THIS or not to THIS

A classes methods can often reference its instance state or accept values as parameters. When should we use one technique vs the other?

If you think of an object lifecycle as starting, control, transformation methods. Constructors for starting, all public methods are control methods and private may be transformation methods.

Principle: Encourage pure functions, discourage object state.

Rule 1:

If the method it initializing an object then reference the object properties. 

func (x X) init() { x.foo = 1 }

Rule 2:

If the method is coordinating a request to the object then use the object properties. All methods that coordinate the operations performed on state are control methods.

func (x X) Control() { makeAChange(x.foo); return x.foo }

Rule 3:

If the method is changing an objects state only use parameters. Methods that change state should be simple to test and lend themselves to refactoring to other classes. These are usually private methods.

func (_ X) makeAChange(foo) { return foo + 1 }

Catch Exception is Evil, Except When Required

Never write "catch (Exception e)" unless you can enumerate the reasons why it is acceptable.

A try catch allows us to intercept situations in our code flow that occur somewhere down a call stack. Generally associated with exception flow but not restricted to that concept.

Primarily talking to C# (or Java) Exception semantics but applicable to other languages to different degrees. An exception is a class that inherits from a based Exception allowing it to be "thrown" for later "catching" higher up the call stack.

The "System.Exception ("java.lang.Exception") represent the top of a hierarchy under which all exception types must be declared.

So this is where the problem starts. The following code is evil and should never be used unless you understand what the exceptions are (pun intended).

try {
  // do something useful
}
catch (Exception e) {
  // react to problem
}

Because the class Exception exists at the top of the hierarchy all exception types created for the application or system types will be caught. For example, a catch Exception will intercept a NullReferenceException (NullPointerException) what should only occur for a coding bug and never in normal production flows. All exception flows should be handled intentionally using the specific thrown class only.

One of our goals as programmers is to ensure we see all coding problems early in the coding process leaving only intentionally handled problems to show up in production. Hiding coding problems leads to production systems that blindly fail without any repercussions.

So why would you use this construct?

Control Loops

If you are writing code that exists in a root of an application, like something in a Main method, that is expected to handle all the situations that occur in a running process, then a catch Exception might be warranted.

    static void Main(string[] args) {
      var count = 2;
      var running = true;
      while (running) {
        try {
          Console.WriteLine("Hello World " + count);
          if (count-- == 0) running = false;
        }
        catch (Exception e) {
          Console.WriteLine("Unexpected error: {0}", e.Message);
        }
      }
    }

These kinds of constructs would want to control situations like unexpected exceptions and log them for review. An exception that is not caught and ends up being thrown to the runtime may only be reported to standard out and perhaps be lost to anyone trying to determine why a program crashed.

Framework Isolation

If you are developing an application that expects to load and run a dynamically loaded 3rd party library then you will want to isolate the management of all interactions with that library. These are interactions you can not test for so protective steps are necessary to ensure predictable outcomes.

try {
  var dll = Assembly.LoadFile("hello.dll");
  foreach (Type type in dll.GetExportedTypes()) {
    var hello = Activator.CreateInstance(type);
    type.InvokeMember("World", BindingFlags.InvokeMethod, null, hello, new object[]);
  }
}
catch (Exception e) {
  Console.WriteLine("The DLL shouldn't have done that");
}

In this manner all interactions will protect the management program and allow for positive feedback to the user or developer of the dynamic library.

Thread Entry Points

The final situation that might require a catch Exception occurs when starting a background thread that throws an exception. For similar reason to catching in a control loop, the threads stack is started at a method specified at launch time and any thrown exception flows up to the runtime in the context of the thread, never returning to the launching thread.

So, if you spawn a thread and want exceptions handled in a specific manner then a catch Exception might be warranted. DotNet and Java runtimes swallow any exception from a background thread only reporting them to standard out so they may be missed during development and certainly not logged in a normal production configuration.

try {
  new Thread(MyThread).Start();
}
catch (Exception e) {
  // This will not catch the threads exception.
}

public static void MyThread() {
    try {
      throw new Exception("Thrown in threads");
    }
    catch (Exception e) {
      Console.WriteLine("Threads should report their exceptions");
    }
}

This means that all thread starting code should wrap thread entry points in a simple management method to ensure consistent exception handling throughout the application.

Common Arguments

These basic rules are ignored for a few reasons. The most common is "I do not know what exceptions might be thrown so catch Exception makes my code safer". To begin with, it is the responsibility of a programmer to know what their code is doing, so "I don't know" is never the right answer. Secondly, you must test drive all possible outcomes from your codebase, which ensures you will know what can be thrown. Additionally, if you miss one, you want it to be made very obvious so that you can fix it as soon as possible instead of failing secretly.

Another concern is that processes should never crash in production. Unfortunately, when the catch Exception solution is used for this it also means processes ever crash in development. So instead of ensuring your program works because you intentionally designed it that way, it only secretly says up in a failing state like some diseased animal hobbling through the woods.


The last excuse excuses the practice of using catch Exceptions offering that each must result in a log message so that the problems can be fixed. This results in volumes of log messages and the inevitable conversations that start "Oh, that exception is expected, don't worry about it" as all the critical log messages are lost amongst the chaos.

If you are making these arguments today, I suggest amending your ways.

May your exceptions be intentional and your reactions true.

Team Culture - Belief

We know that teams need to see the future and feel part of its creation. We talk to roadmaps and share in decisions that re-enforce our shared understanding.

However, we spend a lot of time "doing" because we think we have to. Teams only thrive when they understand the future and become part of creating it.

• We want people to act as they believe.
• We want people to act because they believe.
• We want people to listen and learn because they know there is more than they know.

Don't follow when there is an opportunity to understand and share the lead.

Be willing to argue

Be willing to fail

Be willing to champion

Be willing to learn

Be an advocate of our shared intent.

Coalescing free, individual opinions into a shared opinion is what good teams do.

Agile vs Rigidity.

I think we humans have a problem expressing decent without recognizing existing value.

A system with invented boundaries, requires that people decent when the boundaries are breached.

A system with intentional boundaries requires that those boundaries are challenged.

The evolution of a flexible system is an interplay between the intentional rigidity of good rules and the intentional experimentation of alternatives.

Breaching boundaries is the clue that we are assessing the current rules.

Limiting change is not rigidity, it is the siting of theories that describe optimal flow, each of which requires proofs.

Who Prioritizes Agile Stories. Ops, Security, Devs or the Business?

The problem is an old one; who decides what a development team should focus on next. Traditionally, we say "the business" but we know that product quality and technical debt can loose out. When does "the business" consider security important? Unfortunately, in todays tech world, security is consistently an afterthought.

I believe I have a solution, which stems from trying to understand the question. "Who decides the priority of a story" is the wrong question. It obviously depends on the story. Agile teams profess working together for a common goal, all skills sharing ideas, planning and implementing together, but we never said that everyone on the team knows everything or is skilled or knowledgable enough to make all decisions. Hence the team thing.

So the answer is "Allow prioritization within skill scope" or said more verbosely, "People with specific skill sets make prioritization decisions related to the scope of their skills and goals".

At the end of the day, everyone in the company wants the same thing. Lets make some money, using quality products that are stable and support the services the business sells all the time, and no one wants our products to be exposed to attack.

Story priorities must be defined in this sequence:

1) Production Operations Team

At the top of the list are stories written by the Production Operations Team. These people know how the products they watch over run and are solely responsible for the day to day stability of these products.

Since all businesses want to maintain the services they are selling, it makes sense that a story addressing a problem in this scope must be prioritized first.

An example might be, the automation of a task that results in errors when performed manually. The removal of pageable errors from log files that have no corrective action. A product deployment process that minimizes over night work.

The impact of a problem that this team faces must be reviewed by everyone, but as soon as it impacts this teams ability to operate the products, then they get first dibs at priority list.

2) Security

Next on the list, a security team is responsible for the monitoring, response to attacks and verification that the development teams are building secure products. Any action that detracts from these goals must be prioritized above anything else since it is core to the businesses desire to protect their customers.

A Security Team is responsible for evaluating risk/reward against all possible attacks, but once a protection is deemed needed it gets into the next sprint, right behind any outstanding Production Operations stories.

An example might be, add validation to a field to prevent an injection attack. Integrate a static analysis tool into the CI build to invest in continuous verification of code.

3) Development Team

A development team is responsible for the building and delivering of quality products to production. They are responsible for ensuring they can perform their duties fast and efficiently and with zero defects.

To address this responsibility the Development Team must write stories that address items that might jeopardize their success. It is within their rights to define how they can best achieve the goals of the team.

An example might be, remove duplicate code to eliminate potential bugs. Implement a test framework that will ensure the code always works. Re-write a legacy code module that continues to introduce bugs to the product and slows down feature delivery.

The Development Team also wants to deliver quality features as fast as possible so is responsible about how they asses the risk/reward of changes.


4) The Business

Does it seem strange that the lowest priority group to set priorities is The Business? This was a revelation to me. I thought of it in a tribe retrospective a few weeks ago, when someone asked  a simple question, "Why did we let ourselves create this problem"?

The phrase "The Business" is mis-used of coarse. A company has many departments performing functions that sustain happy customers. IT is one of those departments and is therefore also "The Business". The mixture of skill sets hired by a company including, accounting, purchasing, HR, and programmers, all allow the business to achieve its goals and make money.

So, lets state it this way, if a department in the business needs some changes in a product, then various skills will be involved to achieve that; IT, support organizations, BI groups, operations teams, sales and marketing, training and the list goes on. To make a change to an established product, lots of stuff has to happen and all those teams are responsible for performing their duties to best achieve the companies goals.

Planning that change and prioritizing it against all the other changes from all the departments is part of the business benefit evaluation that occurs to produce road maps.

In the end, that change, written out as a set of stories, optimized for MVP, and evaluated by the development teams to maintain the road map, gets slotted in to the list of stories that the team must work on.

Fear

I hear you say this is crazy. The business pays me and can fire me? What if the developers decide to take 6 months to make the code pretty, you know how much they want to get rid of all those tabs and it takes them so long to get anything done as it is?

Trust between groups is always a challenge. Different people with different skills and different goals will never completely understand each other so mis-trust is easy. However, people are a companies most powerful asset, so fix that first, and allow them to thrive together.

Conclusion

The most efficient way to move forward is to optimize how each team works. Let the developers prove they can deliver features fast. Let security make our customers safe by allowing them to drive how these products should protect them. Let operations teams sleep well because they know how to optimize their work. With these goals, all "Business" changes will be delivered fast and without question.

Tribe Level Ceremonies

We take new words from Spotify to describe a scaled agile organization. Tribes contain squads which deliver features. Guilds share subjects and Chapters share skills.

This is about extending traditional Agile to optimize for larger teams. Scrum talks of teams with daily Stand Ups and a Scrum of Scums to share between teams. It assumes that information is shared between teams via a Scrum of Scrums representative but this doesn't really work.

We don't do team Stand Ups anymore. We don't do Scrum of Scrums anymore. Instead, all Squads in a Tribe attend a daily Stand Up and share red, yellow, green status of the Squad. Thirty people in one room for 10 minutes. Thats four Squads in one room for 10 minutes. Thats four announcements of green most days, occasional yellows with some details and followup actions assigned and a rare red where everyone takes note and assesses how to change resource, blockers or what ever it takes.

This benefits us in a few ways. We decided a long time ago that a Squad Stand Up with a single developer reporting "Finished X, moving on to Y today, no blockers" was not effective. Its not effective because the information is too detailed for most listeners, and redundant for everyone on the Squad because they are all working and communicating everyday. The goal of Stand Ups is to decide if the current plan needs changing and how to change it. Everyone knows the current plan so no point reiterating it but risks and blockers potentially drive change and that is the key that these discussions should focus on.

So, from the old Stand Up definition.

- Please tell everyone what you did yesterday, what you are going to do today and any blockers you have.

We now have a definition:

- Your Squad must indicate the red, yellow, green status of your Sprint commitments and, if not green, what the projected problems are.

This change is made possible because these people have been doing Agile for years and so the need for a single team to "share status" every day is irrelevant now, they do that all day. They all sit within 10' of each other and openly announce issues as they occur. They commit and push code all the time and they ensure the build is always watching them.

If you have developers sitting in cubes, don't do this. If you are new to Agile, don't do this. The habits of the people on your team can not sustain this kind of automatic behavior.

How do you know if you can do this? Do you feel an uneasy fear if you have't pushed for more than 15 minutes? When you pull do you look at the code changes and immediately give feedback? Do you feel strange not having someone sitting next to you arguing with your approach to a problem? Would you feel comfortable if the code you just pushed was to be release to production now.

People go through changes when they practice Agile. Its more than a process, its a re-programming of a developers instincts. 

Making Change a Habit

I adopted a new rule in 2000 that states, "If you think the problem can be solved by just trying a little harder, then you have the wrong solution". We spent decades of wasted time telling ourselves to just try harder to write tests, then TDD came along and it was obviously a better answer.

The try harder admonishment is an endless, repeated, diatribe about of our personal failures and how we should just buckle down and be better. Stop trying harder and start thinking.

I am not saying that, on an individual level, we don't have things we can do better at, and need to be pushed and cajoled into doing something about, but as an answer to an industry of professionals that work hard to build the best solutions they can, "try harder", is wasted breath.

Some things we here today are "Developers just have to try harder to make their code secure", this will never happen so just stop saying it. Instead, change the process to make security a primary focus on every team. Add a security engineer to every team who only, reviews, writes tests and verifies a product evolves appropriately. Enterprise level security initiatives are valuable but are not the full answer, as evidenced by the hacked reality we see every day.

Have you heard this one; "We have to try harder to share information from Scrum of Scrums with the rest of the team". I get that some of you probably do this well, but most do not, and the solution of trying hard doesn't work. Getting the right information into the right minds at the right time is an adventure in frustration. However, allowing for time-to-share and getting how-to-get-information concepts shared is much easier. The human brain works well in a limited number of prescribed scenarios and no-everything-all-the-time is not one of them. Optimize focus, intentionally limit sharing till required and allow time for understanding.

What about from your ops team; "If developers would only try harder they would understand the operations requirements and build the products we could use". Does your ops team hate you? If you are doing it right, a member of your ops team is sitting next to you for some hours of the day talking to you about what they will need to operate the feature you are adding. DevOps is a hard change, do it. Add operational intelligence as an aspect of every feature you implement with acceptance criteria and functional tests. Think of it as BI for the operations teams.

Has  your business every asked you to try harder to get BI reports out faster? "Why does it takes so long for the reporting about a feature to come out after the feature is in production? BI teams and dev teams are usually separated. This doesn't work. Every feature has a BI impact and needs consideration at the time the feature is implemented. Release your feature and the BI reporting as one package.

We have a support desk that answers the phone every day, and they hate us. "Oh please try harder to ensure we can answer customers questions. Just try harder to tell us what you are changing". How do we get support teams, with the hours they work, synchronized with feature development activity that we are working on. Send an email on release day? Sure that will work. "Oh, by the way, that button you used to use, just moved, good luck."  I don't know what the next change needs to be for this one, yet.

If you and your team want to be better, first change how you do things, then measure, and then change again. If you are not changing, you make it hard to change, and inevitably become a lagger in the ways of our ever improving approach to our profession.

If you believe that change damages teams because it introduced confusion, then you see change as an obstacle and will never master it. Don't use change as a tool, if you are not ready. With change comes chaos, and only teams experienced with change know how to own chaos. If your team members do not communicate, do not challenge each other and are not willing to be part of a solution, then change will destroy them. First empower the team, then master change.

On an experienced team, what happens is, a team member sees a change, and reacts by calling the team to order and facing it, they argue about how to address it, devise an approach to it and then reengage to the mission.

Change does disrupt, but since it offers the opportunity to grow, mastering it must be a primary goal.

Change is exciting.

RubyConf 2013 - What Changed?

I have noticed that the last few Ruby Conferences I have attended, Ancient City Ruby and Ruby Conf 2013, have not lived up to some of my expectations. This is not a fault of the conferences but of how I perceive improvements.

In the early days of Ruby, relatively speaking, when all the giant advancements were being made, like Rails, gems, migrations, rake, Capistrano and _why's latest ideas. I am sure we can all have our own lists of world altering ideas that fundamentally changed how we work every day. Some of this radicalization has waned.

I have been reflecting on how progress can be measured by tiny changes as well though the impact is slower and less measurable. For example, Jim Weirich works on Argus and, then Artoo changes how we approach Robotics in Ruby. Independently they are simple API's, but that simplicity becomes a fundamental driver of adoption and the growth of new ideas.

John Mair works on an improved Ruby shell and that simple improvement drives some re-birth of Small Talk ideas. What I can edit and interact with code at runtime? Small Talk got to where it is for many reasons both good and bad, but what will happen when we re-grow the good ideas into something new?

For me, I am going to pay more attention to the micro-drivers of our future. Keep it simple so that we can all be part of the growth.

Ruby is creating a thrilling world.

Ruby Warrior - Game Emulation

Emulating the black box behavior allows us to build tests that prove your code works, as long, as the emulation remains close to the real thing. The Ruby Warrior runtime has features within it, that I do not know yet since I am still at level 7.

The output from my game emulator looks nice and allows me to great new alternative levels that exercise all the features of my player that I wish to.

GAME START
| ^     >|
|  ^    >|
|   ^   >|
|    ^  >|
|     ^ >|
|      ^>|
|       ^|
GAME OVER: ALIVE
GAME START
| ^ C   >|
|  ^C   >|
|  ^    >|
|   ^   >|
|    ^  >|
|     ^ >|
|      ^>|
|       ^|
GAME OVER: ALIVE
GAME START
| ^ S   >|
|  ^S   >|
|  ^S   >|
|  ^S   >|
|  ^S   >|
|  ^S   >|
|  ^S   >|
|  ^S   >|
|  ^S   >|
|  ^    >|
|   ^   >|
|    ^  >|
|     ^ >|
|      ^>|
|       ^|
GAME OVER: ALIVE

A simple rspec runner of these game layouts and a way to encode the game boards makes setup easy.

 describe "Game" do  
  let(:player) { Player.new }  
  
  it "plays empty board" do  
   game = Game.new("    >")  
   game.play(player)  
   
   player.should be_alive  
  end  
   
  it "rescues a sad caged pair of eyes" do  
   game = Game.new("  C  >")  
   game.play(player)  
   
   player.should be_alive  
  end  
   
  it "attacks some sludge" do  
   game = Game.new("  S  >")  
   game.play(player)  
   
   player.should be_alive  
  end  
 end  
   

The simple Game runner.

 class Game  
  def initialize(pieces)  
   @pieces = pieces  
  end  
   
  def play(player)  
   warrior = Warrior.new  
   warrior.board = Board.new(@pieces)  
   
   puts "GAME START"  
   while (warrior.alive? && warrior.on_board?) do  
    puts warrior.board.with_player_at(warrior.position)  
    player.play_turn(warrior)  
   end  
   puts "GAME OVER: #{warrior.alive? ? 'ALIVE' : 'DEAD' }"  
   
   warrior.alive?  
  end  
 end  
   

Ruby Warrior - Trying Again

It is clear that a solution to a problem like this can't just be imagined out of thin air. I am just not that smart. Just writing if statements was satisfying and productive to start with but once level 7 hit and I had to change direction there was no alternative but to throw everything away and start again.

This time, I decided to create a fake warrior implementation, an write some rspec tests to ensure that the actions I chose were appropriate. Then "release" (copy) that code to "production" (paste) to see if it worked there as well.

With this approach, I am making headway but can only solve level 2 because I haven't reimplemented the resting process yet.

Warrior Fake

class Warrior
  attr_accessor :position
  attr_accessor :board
  def self.at_position_1
    warrior = Warrior.new
    warrior.position = 1
    warrior
  end
  def self.next_to_sludge
    warrior = Warrior.at_position_1
    warrior.board = [:sludge]
    warrior
  end
  def initialize
    @position = 1 #zero based
    @attacked = false
    @board = []
  end
  def walk!
    @position += 1
  end
  def attack!
    @attacked = true
  end
  def has_attacked?
    @attacked
  end
  def feel
    @board
  end
end

Player Implementation

require './warrior_fake'
class Context
end
class Action
  def self.choose(warrior, context)
    if !warrior.feel.empty?
      Attack.new
    else
      Walk.new
    end
  end
end
class Walk
  def run(warrior)
    warrior.walk!
    warrior
  end
end
class Attack
  def run(warrior)
    warrior.attack!
    warrior
  end
end
class Player
  def initialize
    @context = Context.new
  end
  def play_turn(warrior)
    action = Action.choose(warrior, @context)
    action.run(warrior)
    warrior
  end
end

Specs

require './spec_helper'
require './warrior_fake'
require './warrior'
describe Player do
  let(:player) { Player.new }
  context "walking" do
    it "moves forward" do
      warrior = player.play_turn(Warrior.at_position_1)
      warrior.position.should == 2
    end
  end
  context "sludge" do
    it "notices sludge" do
      warrior = player.play_turn(Warrior.next_to_sludge)
      warrior.should have_attacked
    end
  end
end
describe Action do
  let(:context) { Context.new }
  let(:warrior) { Warrior.at_position_1 }

  context "construction" do
    it "walks forward" do
      action = Action.choose(warrior, context)
      action.should be_a Walk
    end
  end
end
describe Walk do
  it "forward" do
    walk = Walk.new
    warrior = walk.run(Warrior.at_position_1)
    warrior.position.should == 2
  end
end
describe Attack do
  it "forward" do
    attack = Attack.new
    warrior = attack.run(Warrior.next_to_sludge)
    warrior.should have_attacked
  end
end

Thank-you Ruby Warrior

I just ventured into the dungeons of the Ruby Warrior and spent an hour of my life that I can not get back, but would like to if that is at all possible. What a great time to be writing ruby, to program a knight, in a live dungeon.

Ruby Warrior

I made it to Level 7 before my code was so complex that refactoring is inevitable. I count at least infinity code smells in this. Flags, single method, no intentional behavior, no single responsibility. I am considering some UI testing tool to prove that I can pass each level with the same codebase.

Good times.

class Player
  def play_turn(warrior)
    if !warrior.feel(:backward).empty?
      if warrior.feel(:backward).captive?
        warrior.rescue! :backward
        @saved_captive = true
      else
        warrior.attack! :backward
      end
    elsif !warrior.feel.empty?
      if warrior.feel.captive?
        warrior.rescue!
        @saved_captive = true
      else
        warrior.attack!
      end
    elsif warrior.health < 20
      if warrior.health < @health
        if warrior.health < 12
          warrior.walk! :backward
        else
          warrior.walk!
        end
      else
        warrior.rest!
      end
    else
      if @saved_captive
        warrior.walk!
      else
        warrior.walk! :backward
      end
    end
    @health = warrior.health
  end
end

Waterfall Disease - Symtoms, History and a Cure

It is easy to spot the symptoms in aggressive cases but can present in subtle ways as well. It effects individuals and teams and is communicable. The cure is long and slow but the young heal much faster. If you have been infected with this disease for more than 20 years, the chances of a full recovery is slim.

Symptoms

A programmer feels the strong urge to open a documentation tool before a code editor. This is not a guarantee of infection but a strong indicator.

An infected team will wait for a task to be given to them and then talk about how it is the wrong task or how long it will take to implement. Similarly infected product owners will first ask how long before asking what should be accomplished.

A programmer will, when asked what it would take to implement a feature, answers in terms of the complexity and duration. For example, "OH that would be difficult, we would even have to change the code", or "We would have to talk to that other team, so that will take much longer".

An infected team or programmer assumes that the deadline means they will have to hack in a bad fix, even when there is no stated deadline. These individuals just assume that they will be pushed to make bad decisions so make them as the default, as thought there is no other approach.

A team member states "that is his responsibility", or makes a suggestion or proposal for a change like "I think we should do X". Each of these forms of communication relinquishes responsibility to others, ensuring that the team member does not have to take ownership of the idea they are sharing.

A team member will hand-off a task with the statement "you need to do X so that we can accomplish goal Y". This team member will, and watch for this for it is quick, turn on their heals quicker than normal, and walk away with a slight smile believing they have helped but actually are just passed the blame.

An infected team member will act out, taking actions in direct opposition to the teams goals, and other infected members will watch as though they have no control. They are thinking that the boss should fire that person, not realizing that they should also be considered.


History

Waterfall disease has been with us for decades. Until the late 1990's it was thought of as normal, even part of the best practice of what a programmer was. Only as the year 2000 approached and the new Agile medicine was introduced to the market did everyone start thinking that there might be another way.

Unfortunately, this Agile medicine tastes very bad and patients remain in denial of the problems, just because of that possible bad taste. It is not uncommon for teams, thrashing uncontrollably and screaming about the unacceptability of their plight, to also state that "the medicine will never work" and refuse to sign-up for the treatment program.

Cure

The treatment for waterfall disease is not easy and takes time. Unfortunately, this conflicts directly with the infected parties who have no patience for change.

The cure comes in 3 main phases: a strict diet of learning, combined with the constant guidance of mentors to re-map the brain pathways and finally a change inoculation.

The learning pills must be dosed carefully across time to avoid overload. An ideal learning pill regimen might look like this though results may vary depending on how acute the infection is.

• Complete removal from the environment that promotes the infection. This might mean leaving the programming environment, the building where re-contamination is possible or even, in the most aggressive cases, leaving the company that actively promotes the disease, is the only way to avoid a relapse.
• Daily doses of TDD to begin with interspersed with insights into why the current feelings they are experiencing are actually not normal. Knowing that they have a problem is an excellent step toward recovery but do not expect this to occur in these first rounds. Continue this repetitively for 2 weeks switching from a training environment to a practice environment until you start seeing the natural antibodies of the human body kick into gear. These changes show themselves in the form of surprised questions like "so this actually means I don't have to fix bugs anymore"?. Be gentle with the initial naive questions for the physical changes that are underway are only loosely bonded.
• At some point a sense of wonder, and excitement about the future starts to seep in. Recognizing these moments is key to cementing the changes and reducing the possibility of relapse. Show your excitement about the future and talk of your new life, clean of disease.
• Once two "sense of wonder" moments have passed it is time to move to the next phase of treatment. Collect one or more of these patients into a team and task them with a green field solution. The use of a green field solution simplifies the continuing diagnostic work that is going to be necessary as the work progresses. This also starts the mentoring phase of the cure.

The mentoring must be administered throughout the process for at any time, day or night, an infected individual will take an action that completely undermines their cure. Examples, might be:

• Mid-night implementation of a new feature. Attempted under the guise of improving the teams velocity (and they will use that word even if they do not understand it), but actually, this action is driving a sense of self-congratulatory excitement of achieving goals without the mentor's gaze and without tests. Protect against this with early investment in fully automated functional tests. The next days failing build will identify the culprit and allow the mentoring to focus appropriate action.
• Active creation of cliques, through a sub-team secret design sessions that can then be presented as great successes to the team, when in-fact, they serve more to isolate and inject mistrust amongst the team members.
• Little code changes without tests will leak into the codebase, often with a source control comment unrelated to the change or misdirecting the mentor to a larger change. When challenged the response will likely be a sheepish grin, as though that still works now that they are fully grown up adults, and the statement like "that was just a one character change", or "its only in a tool, not the real app". These are actions that must be stopped, in group therapy sessions, to ensure that everyone agrees that they want to be cured.

The change inoculation is where most of the physical and mental pain is experienced. Analysis of relapsed patients bring to light complaints about the deep personal loss of family pictures and the requirement to move that caused discomfort. Screen sizes, keyboard types and strange IDE's are many of the hurdles that patients must push through. Also they will attempt apparently logical arguments explaining why sending an email is fare faster than walking 10 feet; "plus they have a record of the conversation don't they? Perhaps they want to refer back to it later? They won't have to come and ask me again? Just consider the time savings of not having to move."

This phase should not be trivialized. Your patients complaints will seem small and full of self-interest but they are one of the biggest drivers of resistance to the medication. Failure to attend to these details will initiate a slow drift back to habits that are more comfortable. Many retrograde steps will be subtle, almost imperceptible; a head turned to the floor during a standup, an extra second of reluctance to approach the board and be part of the team. The feelings of isolation, and failure will compound this situation accelerating the relapse.

The inoculation itself can take many forms but centers around making change the norm through the use of intentional disruption. For example,

• Throw away all desktop computers and replace them with laptops to promote movement. In the same vein, ensure that wireless network access is available and the old wire is disconnected.
• Interrupt the team with cake but do not take it to their desks. Instead, place it 20 feet from them so that they are encouraged to move. Repeating this makes movement more normal and bridges the gap to a time when movement to communicate with team members is the new habit.
• Mandate pair programming and make sure that it is with new people all the time. Having to work with team mates ensure that they know each other's names and start gaining insight into other cube silo's.
• More radical, but utterly required to ensure success, is the removal of cubical sitting structures. Some powerful conversations with CIO's will be necessary to drive this kind of medication. 
• Disabling email for periods of time forces movement for simple conversations, changing the quality of communication so much that teams will start experiencing a high velocity team feature known as "common thought". At first this is startling, and must be called out by mentors as a healing step, but will soon become the natural order in which simple 30-second exchanges can accomplish what was once days worth of drifting, misinterpreted email exchanges.

The change inoculation is fraught with complaints like "but I liked my privacy" and I would rely on your mentor to resolutely and clearly state the futility of these gestures. Perhaps offer "we could build you your own office if you like" or "aren't we all so lucky to have private homes to go to". Lean on the emotional content of these interactions, logic is not as effective in this inoculation process. Only the emotions of team membership and commitment to common goals will drive the lackadaisical thoughts from the air. These thoughts are drivers of relapse so be attentive in all locations: sit with the team in the team areas, be there in break rooms, and accompany likely offenders during the walk to their car, especially if they are accompanied. Contamination is an ever present threat.

This cure is a 3 to 6 month process and after the 6 months is over the need to continue to encourage advanced learning is critical to maintaining the positive progress.

Waterfall disease shares a similar trait to alcoholism. Once infected, you will always carry the old urges. Even well established mentors have been known to succumb to the comfortable old habits of believing their code actually works without tests. Why just yesterday, I was party to the disabling of thousands of distributed machines because I knew of a change being made and said nothing about it not being tested.

Yes, I have waterfall disease.

Ruby, SSL and Untrusted Certs

It has been a long time since focusing exclusively on writing Ruby code. So much fun.

The last two years have been groovy only which is a great language but there is something pure and simple about Ruby that just takes your breath away.

Enough of the emotional stuff, why, on earth, is it so hard to disable SSL cert trust verification. Such a common problem, google is full of Rails ActionMailer solutions but of coarse that doesn't help the rest of us.

Ruby 1.8.7

I approached the problem from Net:HTTP library makes it pretty easy. You just have to remember to require the correct classes and note that you are not disabling SSL just the trust verification part. # irb(main):001:0> require "net/https" # => true # irb(main):020:0> h = Net::HTTP.new("YOUR_SSL_SERVER",443) # => #<Net::HTTP YOUR_SSL_SERVER:443 open=false> # irb(main):021:0> h.use_ssl = true # => true # irb(main):022:0> h.verify_mode = OpenSSL::SSL::VERIFY_NONE # => 0 # irb(main):023:0> h.get("/") # => #<Net::HTTPOK 200 OK readbody=true>

My actual goal was to access a WSDL, over SSL, with an untrusted cert. This was not so easy. Took me about 5 hours to work out this solution. Expensive.

I used the Soap4R gem and since performance is not an issue I figured the dynamic proxy from the WSDL parsing would be the way to go:

factory = SOAP::WSDLDriverFactory.new("#{@url}?WSDL")

The problem was that there is no simple API to set the verify_mode of the connection so you have to root around in the code until you find where to monkey patch. This is what I came up with.

# # Monkey Patch HTTP Client # Sets SSL verify mode to NONE so that we can connect to an SSL server # that does not have a trusted certificate. # class HTTPAccess2::Client def initialize(*args) super(args[0], args[1]) @session_manager.ssl_config.verify_mode = OpenSSL::SSL::VERIFY_NONE end end

If someone has a cleaner solution I would love to hear it.

Ruby 1.9.3

Upgrading to 1.9.3 broke my Monkey Patch as expected so here is the updated one that handles both for the time being:

# # Monkey Patch HTTP Client # Sets SSL verify mode to NONE so that we can connect to an SSL server # that does not have a trusted certificate. # # The 1.8.7 patch adds a new constructor. # The 1.9.3 patch intercepts the existing constructor now that the class # name has changed. if RUBY_VERSION == "1.8.7" class HTTPAccess2::Client def initialize(*args) super(args[0], args[1]) @session_manager.ssl_config.verify_mode = OpenSSL::SSL::VERIFY_NONE #@session_manager.debug_dev = STDOUT end end else # > 1.8.7 class HTTPClient alias_method :original_initialize, :initialize def initialize(*args) original_initialize(args[0], args[1]) @session_manager.ssl_config.verify_mode = OpenSSL::SSL::VERIFY_NONE #@session_manager.debug_dev = STDOUT end end end

Southwest Ohio Give Camp - Review

Ending with the demo of the charities new sites and the excitement on their faces as they looked up at the giant screen, was certainly the best thanks we could have received.

Photos

Moments.

Arriving back at the MUVOALC early Sunday morning to find volunteers outside banging on the doors and windows trying to get in. Six a.m. days are no match for these awesome people.

The 10 year old son of one of the volunteers asking how he can help. Dropping the xbox controller to rush off to notify the teams that more pizza had arrived.

The quiet that descended on the team rooms as everyone focused on doing their best work.

Team leads complaining that they don't want to wait 15 seconds for a standup to start because they have customers waiting.

Volunteers with decades of experience reveling in talking about what their young team members have been producing.

The worry expressed by people that working till 3am would not be enough and would the charity like what they have done.

Hearing the charities talking about "their developers", bringing then brownies and taking group photo shots.

10 Charities, 10 Solutions

Elementz (temporary url)
Seton Family Center
John 15:12 Ministries
Post Secondary Education Collaborative
Hamilton Living Water Ministry
Diabetes Dayton
Working in Neighborhoods
Civic Garden Center
Dayton Battle of the Businesses
End Slavery (temporary url)

Conclusion

As much as we were thanked for this one weekend, it is clear that the charities themselves have 51 others this year to do their work. These are the true champions of this weekend. It has been a privilege to get to know them and offer a small amount of assistance.

Southwest Ohio Give Camp

On October 22 through 24th we are running a Give Camp located in Southwest Ohio. Collect your project manager and developer friends and we will connect you with a team to help out a Charity for one weekend. This is a great way to use my professional skills for a good cause.

http://southwestohiogivecamp.org

We have an awesome group of volunteers putting the event together. We are organized into 6 teams to ensure we have a focus on the various areas that have to be worked on.

The Charity team focuses on identifying Charities, collecting the details about what they need. Our goal was to support 10 charities and we already have 20 submitted proposals. This team is comprised of Andy Erickson (@axerickson), Eric Schwartz (@SchwartzE), Darrell Hulshult (@dhulshult) and Andy Douglas (@GoodPiper) all doing an amazing job pulling together all these organizations to coordinate so many successful projects. Just imagine the problem of running 10 projects simultaneously in one weekend.

The Developer team focuses on setting up the website and attracting all the tallent that will work on the Charities products. With a goal of 50 people, to give us 5 person teams for each Charity, we are now at 37 with 3 months to go. With this kind of ramp-up we may have to consider expanding our goals. This team is made up of Ernie Stormann (@EStormann), Jennifer Griffin (@jengriff), Bill Barnett (@agilous) and Matt Brewer (@MattBrewer).

The Facilities team is responsible for finding the location for the event and managing the setup and orchestration of the event over the weekend. This is a mammoth task, to plan, find and acquire food for everyone, to manage the registration and leading of people to their work environments, and ensuring that everyone is getting everything they need. The idea of 100 people descending on a single location for two days is going to be quite an experience. Fortunately, the team is incredible, made up of Ryan Cromwell (@cromwellryan), Matt Brewer (@MattBrewer) and Sandi Sumerfield. They found a fabulous facility in the Miami University Voice of America location which has the most up-to-date and state-of-the-art video, network and teaching facilities I have ever seen. This building is basically being donated to us for this event because Miami University is so invested in helping the charities in this community.

Miami University's Voice of America Learning Center

The Finance team is just me but I am fortunate to have made contact with some great partners to help me through this process and so many generous sponsors. However, I am learning that the financing of charity events is much harder than for-profit events. It seems that the word Charity discourages companies from sponsoring it. If anyone is interested in donating please let me know.

http://southwestohiogivecamp.org/Home/Sponsor

The Marketing team is a combination of people from all teams since each team has requirements to reach the people they need to reach. I just manage it but everyone contributes what they need. Andrea N. Brady from The Marketing Shop Consultants has been a great help, donating her time to craft articles for publishing.

The process for putting this together starts with lots of enthusiastic smiles and then you start to realize all the details that are involved. The key to success rests on the team you choose. it's the Charities that need to win, not us.

Cincinnati Day of Agile - Registration Opens Today

Registration opens TODAY at noon. Seating for this event is very limited and this event is going to quickly sell out. Do not wait - register today at http://cincydayofagile.eventbrite.com/.

What is Cincinnati Day of Agile?

As the Agile project management process sweeps across the software industry, businesses not understanding the details are being left behind. The Cincinnati Day of Agile is an opportunity to understand what Agile is all about and hear from people that have used it, succeeded with it and have the results to prove it.

At this one day event on Saturday, May 15th, a host of industry experts will be on hand to offer their hard won experiences. By bringing together a mix of developers, managers, Agile professionals, and technologists, the Cincinnati Day of Agile also provides excellent networking opportunities for its attendees. We hope you will join us to learn how Agile can make your software development process more effective, productive, and profitable.

More about the event can be found at http://cincydayofagile.org/.

Kanban - A small practice project

A few months ago I completed my first Kanban project. The team was small and the introduction informal but it went well.



Background

The team comprised 5 people. A technical manager, 3 web developers and me. They managed many projects simultaneously which resulted in a great deal of task switching for the developers.

There were no detailed plans and few team planning sessions. The technical manager was able to keep track of the teams goals on the fly. As tasks and priorities changed, the team would be notified.

Three of the team members had experienced a full agile project in the past which resulted in the team continuing daily stand-up meetings. They stated that they wanted to continue using TDD but that hadn't persisted as strongly. While one of the developers had used TDD in the past, they did not use it consistently, and the rest of the team did not have any training on the technique.

Project

The project was estimated at 2 weeks and involved a UI replacement of an existing web application. A couple of minor business flows were going to change but essentially it was just large segments of the site getting new HTML/CSS. All HTML/CSS was developed by a 3rd Party design company so the in-house work was limited to verifying what was delivered and implementing the designs.

Process

We started with a little presentation on what Kanban is. Ran through some examples of how a project might be run with a focus on software projects. The whole team was in attendance along with a couple from other teams and a Director.

Feedback seemed good with statements like "We need something like this" and "I wish we could get all teams to do this".

From there we got the team together to chunk up the tasks and played Planning Poker to come up with some high level estimates on how long it would take. Each task was written on a post-it note and stuck on a white board in the left hand column ready to be pulled forward into the work in progress.

The columns we started with were:

o Backlog
o Work in progress
o QA
o Complete

Even though "everything had to be done" it was agreed that some were more important than others so a loose prioritization scheme was devised that ensured that the correct post-its were pulled forward first. The manager took on the role of adding priorities to post-its in the Backlog column when needed.

Results

Team members initially needed some encouragement to move the post-its on their own. This soon past as they were offered the opportunity to take control of the work they were going to do.

By the end of the first day we had blocked tasks. We started adding red stickies to the post-its but eventually moved them to a new blocked column between the Backlog and Work in Progress columns.

When asked, the team said they liked the process because it helped them see what was needed and completed.

A great indicator of the teams investment was the exclaimation "Wow, look how much we have got done" as they looked at the completed column full of post-its.

Since the team was switched to and from other projects the estimated two weeks was not an elapsed time but the project was released before the business needed it.

Comparison with Agile

We did take the time to estimate the stories which wouldn't necessarily be part of a Kanban project. However, there was concern about the completion time which needed some up front guestimates to allow the team size to be predicted.

Beyond release estimating, no time was spent planning what tasks should be worked in the first iteration. While it was only a two week project, in a Scrum or XP project we might have tried for 2 one week iterations. Not doing this did save us a little time and since the Kanban board continued to show tasks getting completed there was always a clear understanding that things that were getting completed.

Additionally, without iterations we didn't ever ask ourselves about what to do if we had not finished the estimated work in the iteration. Instead we maintained the column constraints and monitored how long items stayed there.

If this team ran all their projects using Kanban, the lack of planned iterations might allow some projects too fall through the net. This can be handled with simple organizational changes so shouldn't be a risk.

Grand Rapids Give Camp - Cincinnati Satelite - Retrospective

What an excellent time, hanging with friends, meeting new people and the opportunity to help out some charities at the same time.



I first heard about Give Camp when Mike Wood published his involvement at one of last years events. When Mike mentioned Grand Rapids I knew it was something I wanted to be involved with. Only a 5 hour drive from Cincinnati but it turned out that the drive was not going to be possible. Fortunately, with some great support and nagging from friends I decided we needed to organize a Cincinnati based satellite to see if we could help out.

Now that it is over, everyone is talking about doing our own in Cincinnati next year so here are some memories to remind us.

Over the coarse of the of the weekend twelve local developers volunteered their time and were able to contribute to 5 different projects with their Rails, PHP (Joomla/Drupal) and .Net (dotNetNuke) experience. A great diversity of skills allowed this group to really make a difference.

Thanks everyone, you rock, Rob Biedenharn, Brad Leydorf, Phil Japikse, Mark Haskamp, Frank Glandorf, Kevin Longshore, Bill Barnett, Gerard Sychay, Sunil Kommirshetty, Brian Harwell, Andy Douglas.

It was great working with the Grand Rapids team, Chris Woodruff, Ryan Montgomery, Carl Furrow, Luke Rumley, Emily Stoddard and an apparent endless list of others that I never got to talk to.

However, as with all experience, it wasn't just buttercups and blue bells. As a remote team we experienced the usual problems that distributed developers face. We had a hard time connecting with the teams in Grand Rapids. To make Give Camp Satellites more effective they really need full Voice/IM connections with the teams they work with.

On the first night Luke took on the the role of runner and was great at matching the experiences we had in Cincinnati with the work opportunities up there.

The second day involved us bugging people we learned about on the first day to see if we could help. We heard that they were mostly involved with design work and we were not UI people so the pickings were lean to start with. As the day rolled on we started getting more hits and ended up being able to make some real connections and contributing some positive changes.

The last day left us with one, particularly difficult, bug to address which ended up taking input from 5 developers, over 7 hours, to find the eventual 2 character fix. Oh Safari, the pain you put us through.

As the closing ceremony started in Grand Rapids, we had our own celebration with the most popular food of the weekend, a giant bag of M&M's and promises to work on a Cincinnati Give Camp next year.


Thanks to EdgeCase for donating their Cincinnati office space, and for those that work there, letting us use their desks and plug-in to their monitors.

Thanks to Finagilous for supplying food.

Some pictures:

EdgeCase Office
All Volunteers waiting for work
Bill, Frank and Mark
Rob and Bill
Kevin, Ed and Andy
Bill and Rob

Security and Quality through Testing or Process?

As an Agile software developer I talk alot about testing. I promote and teach Test Driven Development and push to change the habits of developers to encourage quality traits that make the software we produce just work.

I want to draw a distinction between the understanding that I am "testing" and the fact that I am following a "process". This may be moot in the grand scheme of things but it strikes me as important because of a sentence I was about to make to a security professional.

Consider this:

As a software developer, my primary goal is to make software work.

A QA developer is focused on making software NOT work.

This is why I am not capable of testing.

Similar logic demands that
I am not capable of producing secure code.

The problem with this logic is that is contradicts everything I teach. Test, test, test but, oh by the way, you are not capable of succeeding.

So, perhaps I should describe TDD as a development process that improves quality instead of a process that tests code. While the eventual result is a set of tests that verify features of code, the developer gets there by following the TDD process, not by trying to make things break.

This is not a statement of whether TDD is a design process or not. Different discussion. I am addressing developer intent, not defining the outcome of the TDD process.

In TDD we first follow a simple mantra:

Run the Test,
Change the Test,
Change the Code,
Repeat every 60 seconds.

Step two of this process could be argued to be an attempt to break code. However, this is not true since all we are doing is writing tests that will break because the functionality is not implemented yet.

TDD offers us a process to ensure that we end up with a suite of testing code that matches our running code. So TDD is not a testing process, just a development process that encourages a higher quality of working code than other processes.

From a higher level, the software development process we use already "values" a Quality Assurance team that double checks the work that we do. These people focus on breaking our code and do a really good job at it. They are a critical step to producing reliable software.

Another important role that software developers are unable to be good at is producing secure code. While we can learn the best practices and gain an understanding of the OWASP Top 10 attacks we are still trying to make software work for the business, we are not trying to prevent customers from attacking it.

Even with this problem, the software development process doesn't "value" a security organization reviewing the product that is produced.

Our industry is just starting to learn how to integrate security intelligence into the software build process and, to date, we software developers do not have a Security Driven Development process to improve our odd for success.

Scott Ambler's 2003 article predicted its creation in 2004 but his predicted internet shutdown wasn't as impressive a game changer as he thought. Unfortunately, that remains a learning curve in our future.

Dynamic vs Static Typing: An Observation

This is a dynamically typed language


pron. This v. is prep. a adj. statically n. typed n. language