It can mean that we should keep things in the open, no secrets or that our doings are audited and we can back-trace them every time we need or want to. In other words, saying that there is not enough transparency means that there is not enough trust. Sometimes the word transparency is used masking the desire to know what is going on.

Demanding more transparency smells a lot like green-washed management. Instead of saying “Keep me posted on whatever you do!”, require transparency. I say it is just a management intent in a disguise!

Thus transparency is attached with a bad echo. Especially if the people involved are not co-located or there are no clear backlogs for work. The person demanding transparency wants to gain assurance that everything is going as planned. This leads to micromanagement and reporting.

In other words, there is not enough trust.

Sometimes the word ‘transparency’ is used to replace the word visibility though. Using it this way is in my opinion harmful because it is very easy to confuse with the previously mentioned management-loaded term. Avoid it.

There are at least two ways out of these situations. One is to increase the visibility, especially if people are co-located, to increase communication. The other way is to build up the trust. Trust that the other party is doing her best.

I’d like give huge thanks to the organising posse for trusting me with a slot! This will be the first time for me to speak in a conference. It’s quite funny since I have participated in exactly one conference, the one that I was organizing.

My presentation is still very much in its infancy, but the topic is quite clear. I will be speaking about software craftsmanship. It’s very important topic for me and I want to share my ideas what it means in practice and what are its consequences. It will be a 45 minute presentation so I will have or should have enough time to consider the topic from multiple angles.

The conference main site is here.

I’m in a team of four very experienced and smart people, we have a product owner who is tech-savvy, knows what he wants and sits in our team room! On top of that we have an excellent room where single every wall is covered with material that you can pin stuff into. We have been given control over our tools and we are given a lot of trust (which is as it should be ;) ). We agreed to start with kanban as our development process and that made me extremely glad since I haven’t been able participate in a real kanban project yet!

We are now roughly two weeks into our green-field project. We started out with a simple three swim lane kanban-board where one swim lane is for product backlog stories, one lane for team stuff (environment, tooling, etc.) and one lane for the PO. Almost all work flow states have a WIP limit of 2, one has a limit of 4. At any time only two user stories can be under work. your basic kanban stuff.

We have the categorised the product backlog stories and pinned them on the wall. They form a vague big cloud, a chunk of things, that we are supposed to make. And this chunk is annoying since it does not provide a coherent vision, idea or goal for the team. Well, of course the goal is make the whole product, but that doesn’t really help in daily work. The team needs a short-term goal and a vision to support its work. The vision could be described as an epic, a collection of stories. Simply put, we need to know where to aim at on a shorter time interval. Our initial kanban board didn’t give this vision but our PO had already defined it and written it down on one of our whiteboards. So it was there for us but it wasn’t part of our kanban board. How could we incorporate it with our board?

I devised a kind of a funnel, a new stage if you will. Epics are pulled from the Big Cloud and placed into a funnel. It will be the teams goal and provide a clear path for us to work with. The contents of an epic are coherent and we can easily see, for example,  interdependencies between stories. It is also extremely useful when we manage to get some data about our lead time to help us estimate when a certain product increment is ready. This can then be conveyed to the stakeholders and business people. We can estimate and tell them when to expect a set of features instead of the whole product or just a single story.

To put it short, we now have three stages in our kanban wall. From the backlog cloud the PO can envision an epic for the team that will guide us to the next composition of increments. From the epic stage we pull stories to the kanban board for the teams daily work.

To some of you this may feel like we are aspiring for things that Scrum gives you out of the box. Well, we are but rather than restricting us with Scrum we are doing things that we feel benefit us and our stakeholders. We have retrospectives, we are going to show (or demo) what we have achieved and we are going to estimate the big chunk of stories. But we do an activity only if it will bring value. For example, if there is no value in estimating the backlog, we won’t do it. But we are going to try things that are deemed valuable either by the team or the stakeholders. And remember that the epic can be withdrawn at any time as it is not taken under work, we still do work only on story level!

I am eagerly waiting how the process will evolve and what is the direction it will evolve?

(picture by cantoni)

stole the boot sector. Some issues with stability though, most likely due to NVidia drivers, which were at least partly solved by installing nvidia-current and running nvidia-xconfig and nvidia-settings as root. So far this has been the best work setup I’ve ever had, plenty of memory and CPU power, the OS I want and no prohibiting policies or idiotic restrictions. Just the way it should be. Anyway, had to make some loops to get Adobe AIR installed so that I could install Tweetdeck (sigh.). Skype was fortunately a painless installation.

Albeit slightly annoying, the tech issues are become fun in the end and after some struggles it was a joy to join again the Nitor irc-channels. So many like-minded geeks there (I was at the office, others were at the customer sites). And immediately there was a  debate about mocks and unit test quality, just the way I like it. Smart people with different views, ideas and wide experience provides very fertile ground for tough discussions and a good place to test ones ideas. And a very supportive group it is. Everyone willing to help the new guy.

I think I’m gonna like this place a lot!

Anyway, suddenly I found myself browsing the Netty documentation. I’ve always had a secret crush with IO so with a little free time in my hands it was a perfect opportunity to explore Netty. Thus, my journey to 7 languages was turned into 7 languages and one framework as I wrote a very crude chat command line application using Netty.

Netty provides very good documentation and the chat app was up and running in very short time. The biggest obstacle was actually generating an executable jar file with dependencies using maven. And even that was solved in less than 10 minutes. So, Netty seems to be an excellent asynchronous, event-driven network application framework. I hope that I could use it for some serious coding @ work!

Now that I’m derailing once again form my original plans, I may have to come up with more strict wip limits for my journey so that I can actually move forward into the direction I want to instead of jumping around everything that seems even remotely interesting.

There was something about Ruby that intrigues me so I convinced myself that I must do something with it. And the easiest and maybe obvious choice was Ruby on Rails and a web application. I’ve heard that it does amazing things to developer productivity so I might as well give it a shot. Now, I’ve had an idea for sometime about a very simple browser based utility which I actually might try to implement now with RoR.

Of course I will enhance my Robot Framework skills by trying do this web app in true ATDD style. Starting with one user story, writing a Robot test for it, running the Robot test and seeing it fail and only then starting to think how on earth am I going to implement this thing with Ruby and more specifically how do implement it doing TDD with Ruby (or should I try BDD with RSpec)?

I will get back on track with Io as soon as I find the strength in me to spoonfeed the compiler and to satisfy the linker…

I found pp, a pretty printer for Ruby data structures, lot in vein of Perl’s Data::Dumper. It is not as good at first glance but my experience with is still in its infancy.

The idea of open classes is marvelous although it requires some discipline from the developer since dynamic typing allows the usage of methods and functionality that might be defined somewhere else. The compiler really can’t know it yet. Improper usage will result in run-time errors. This is one of the major drawbacks of ducktyping. It gives you freedom but with that freedom comes responsibility. Don’t ignore it.

I fiddled a little with modules, mixing functionality into other classes. This is one of the experiments

module Tweetify
  def tweet(str)
    puts "[Tweet!] " + str
  end
end
 
class Speaker
  include Tweetify
  attr_accessor :voice, :s
 
  def initialize(voice)
    @voice = voice
    @s = {
      'loud' => lambda { |str| puts str.upcase! },
      'low' => lambda { |str| puts "[shhh!] " + str.downcase! },
      'default' => lambda { |str| puts str }
    }
  end
 
  def speak(what)
    @s[@voice].call(what)
  end
end
 
s = Speaker.new("loud")
s.tweet("twit twit")
s.speak("am I yelling?")
s.voice = "low"
s.speak("I SHOULD BE WHISPERING NOW")

I learned through a struggle that instance variables must be initialized within a method, otherwise their content is lost. Or I just don’t know the intricacies of Ruby well enough. Overall the books Ruby exercises are good. Exercises touch the parts that Ruby is good at. Something more difficult could be useful and something to be done from the scratch instead of extending the books code snippets.

Now it is time to move forward to the next language (io!) but I would love to stay with Ruby a little longer. I just may have to find something for my own pleasure. Stay tuned!

Code blocks, that is lambda‘s, are something that every language should have. It enables composition of functionalities and reduces code bloat. Let’s see a simple example of ‘grep’ command line utility.

if( ARGV.length < 2 )
  puts "usage: grep <expression> <files>"
  exit 1
end
 
regex = Regexp.new(ARGV.shift)
ARGV.each do |inFile|
  f = File.open(inFile)
  f.each do |line|
    if( line =~ regex )
      puts "[#{inFile}:#{f.lineno}] #{line}"
    end
  end
end

It is not the prettiest piece of Ruby but it works. In this ‘grep’ utility code blocks are used to perform functionality upon iterable elements. Lambda’s enable some cool features like dispatch tables (bye-bye if-else clauses). Simply choose what you want to do:

m = {
  :write => lambda { |input| puts "Wrote: #{input}" },
  :times_two => lambda { |i| puts "Doubled: " + (i*2).to_s }
}
 
m[:write].call("foo")
m[:times_two].call(2)

This is in my opinion pretty cool, although there is some syntactical cruft. The same in Perl would be (with magical characters too)

%m = (
  write => sub { print "wrote: @_\n" },
  times_two => sub { print "Doubled: " . $_[0]*2 . "\n" },
);
 
$m{write}->("foo");
$m{times_two}->(2);

Well, too many magical characters for real readability (there are ways around them, albeit a bit more verbose), but the programmer performance is awesome.

Then the ‘duck typing‘, ultimate source of funky defects. Compiler warnings are most of the time good, but for a beginner overcoming the syntactical issues is sometimes just trial-and-error. Fortunately the internet is full of good Ruby-sites and the community altogether seems very vibrant and alive.

Consider this piece of code

require 'pp'
 
h_of_a = { 'parent_key' => {
    'key_level_2' => {
      'key_level_3' => {}
    },
    'key_level_2_2' => {
      'key_level_3_2' => {}
    }
  }
}
 
#pp h_of_a
 
h_of_a.keys.each do | key |
  h_of_a[key].each do | i |
    puts "h_of_a.keys.each key type: " + i.class.to_s
  end
end
 
h_of_a.each do |key, value|
  puts "h_of_a.each value type: " + value.class.to_s
end
h_of_a.each_value { |value| puts "val #{value}" }

This prints out the following:

h_of_a.keys.each key type: Array
h_of_a.keys.each key type: Array
h_of_a.each value type: Hash
val key_level_2key_level_3key_level_2_2key_level_3_2

Just forget the second argument (value) for the lambda or iterate over it a little bit differently and you can find yourself bitten by duck typing as the variable type is not what you expect it to be. Can be confusing but seems to be something to learn. The amount of methods available is a bit overwhelming.

Ruby has managed to arouse my interest and I’m waiting eagerly to get my hands real dirty with it.

I was convinced at the first glance that this book can give me insight into different languages and provide me with the crucial information what are the strengths of a certain language, what is the language strong at. I discussed this book with my colleagues and generated more income to Pragmatic as they went and bought the book. Wonderful to see people getting enthusiastic.

Anyway, the book starts with Ruby which is why I am writing this. I am planning to write a series of blog posts depicting my journey through this book and its languages.

As a JAPH I loved the concise way you program with Ruby. The syntactic sugars, the arrays and hashes. Mixin’s are an absolutely fabulous concept and the fact the Ruby is purely OO language just adds to the positive side. Duck typing can cause some very nasty defects when it goes awry but with RSpecs and/or TDD approach these pitfalls are easily avoidable.

The first contact with Ruby was very pleasant, I felt immediately at home. The friendship has just begun but I am sure that I will not forget Ruby soon. It has so many bright sides to look at.

Stay tuned. I will continue this series. These blog posts will cover my journey through the land of learning.