Extreme Enthusiasm

The book Object Oriented Programming by Peter Coad and Jill Nicola is a very enjoyable introduction to object thinking. One of the gems it contains is the following:

The “-er-er” principle. Challenge any class name that ends in “-er.” If it has no parts, change the name of the class to what each object is managing. If it has parts, put as much work in the parts that the parts know enough to do themselves.

(For instance: if you have a PersonManager, delete it and move all of its method to class Person.)

Carlo Pescio wrote an excellent blog post on this. Since I discovered this, I found that choosing good names for objects makes it much easier to write good code. It’s much easier to decide where a responsibility belongs.

Now, the team I’m currently coaching with has a Rails project. As a consequence, I’m reading the latest things on object-oriented programming and Ruby and Rails. I read Objects On Rails and from there I discovered Sandi Metz and her chapter on interfaces in Ruby. Sandi really has a way with explaining objects; she has the knack of explaining deep principles in very easy terms; and she does it with examples. Three cheers for examples!

In this video from 2009 on SOLID Object-Oriented Design, Sandi shows how to take an everyday Ruby script and turn it into an OO thinking lesson. Please go and watch it; return when you have :-)

Did you notice the one wart in Sandi’s design? Yes, it’s the FtpDownloader class!! Can we get rid of the “-er” name? What would a better name be?

“Downloading” is an action. What are we doing the action to? We’re doing it to a file. So we could call the class File, but it’s not a great name. You don’t download just any file; you only download remote files. Bingo! Why don’t we call it RemoteFile? My design would have


RemoteFile.new("ftp://server/dir/file.txt").download


This gets rid of a bit of duplication in Sandi’s design. While she would have a configuration like

ftp_host: server
ftp_path: /dir
ftp_file: file.txt
downloader_class: FtpDownloader

I would just have

file_url: ftp://server/dir/file.txt

Instead of providing multiple FtpDownloader, HttpDownloader, SftpDownloader classes I would have a single class that decides how to download based on the protocol in the url.

class RemoteFile
  def initialize(url)
    @url = URI(url)
  end

  def download
    self.send("#{@url.scheme}_download")
  end
  
  def ftp_download; ... end
  def sftp_download;  ... end
  def http_download;  ... end
end

This makes it in my opinion more cohesive than having many single-method downloader classes. If you disagree, you could still use the trick that Sandi uses. But I would still not calling them FtpDownloader. Since they represent a protocol, I would maybe call them something like FtpProtocol. The name of a thing, not of an action.

   
class RemoteFile
  def initialize(url)
    @url = URI(url)
  end

  def download
    # if @url is "http://foo", we get HttpProtocol
    class_name = @url.scheme.capitalize + "Protocol"
    Kernel.const_get(class_name).new.get(@url)
  end
end

If I have an FtpProtocol object, I can ask it to get or put a file at a url. It becomes a magnet for all the functionality that belongs to the Ftp protocol. This would be more cohesive that having both FtpDownloader and FtpUploader :-)

A quick summary of the sessions I attended at Agile Coach Camp Italy.

Fabio Armani — Liftoff. This was a scaled-down-to-an-hour version of a tutorial that Diana Larsen gave at XP2012. It’s about her new book.

Pragmatic coaching — Antonio Carpentieri talked about coaching practices that he uses, and the audience contributed some more. Antonio uses one-on-ones and powerful questions. I remember we had some discussion on how to introduce the one-on-ones. One kind of OOO is used when you get to know a new team. Then you explain the team what OOOs are and why you do them, and you ask each team member in turn to have a conversation. Another kind of OOO is the one that happens by chance, when someone in the team tells you something, or when you take advantage of a “teachable moment” to have a conversation. One thing to remember — if you want to avoid the awkward moment when you say to someone that “you need to talk to him” you can instead ask “when are you free to spend some time with me.” Offer help, or ask for a meeting.

Talking about powerful questions, Antonio mentioned the pyramid of questions, with closed yes/no questions as the least powerful, to “why” questions as most powerful and dangerous. Others mentioned that there are other kinds of questions, like “coaching questions” (I should research some on these) and “surprising questions”, that try to elicit original thinking by asking something unexpected.

The three axes of questions were mentioned: power, scope and assumptions. I assume that “assumptions” means questions that make us question our assumptions, like, what evidence we have of X.

Socratic questioning was also mentioned; Socrates used questions to bring out the truth.

We discussed if the coach should write many notes during the OOOs. Pierluigi said that he does not write much, except when he notices particular reactions in the coachee, expecially emotional reactions. He writes a note so that he will probe further on that later.

There was some discussion on two polar opposite way of being an agile coach: one uses nothing more than a kanban board and retrospectives to drive change, with no plan in mind; the other starts with an explicit program to introduce (say) Scrum. The first kind may take forever to produce benefits; the other may push the wrong solution.

Claudio Perrone says that he always starts new coaching engagements with a retrospective, so that he gets knowledge for deciding what to do next. Then if he thinks that a particular method or practice is needed, he will ask the team *permission to be directive*. This is because some “telling what to do” is needed when the team is not expert enogh on a given method or practice.

Other practices that were suggested:

• The high-performance tree, that I read about in Lyssa Adkins book
• Shut up, use uncomfortable silence to get people to fill it with what they think.
• Let the people tell you their own story; ask them about it.
• Use the 4C technique from the book “Training from the back of the room”

Pierluigi Pugliese — Train your coaching awareness. Think how many different things you can do while you are listening to someone explain a problem they have to you. For instance you can offer solutions, or ask probing questions, or question the assumptions, or question the statements, or you could sit silently, using silence to prod the person to speak further. There are many, many things you can do, and everything that you do or not do produces an effect in the conversation. This session was about trying some of these modes of interaction and observing the effects on the coach and the coachee. All I can do at this stage is to work on my awareness of these effects; I don’t have any explicit knowledge of which modes to use to help the coachee in any given situation.

Roberto Bettazzoni, Gaetano Mazzanti — The Cynefin Lego Game. This game explains the Cynefin model by means of a sequence of Lego construction task. You can find the details of this game on Agile42’s web site. One interesting observation by Taz is that the coaches are particularly good at solving the tasks; he says developers are usually worse, and managers make the worst job of it!!!

One *useful* thing I got from this session is the explanation of why there is a “fold” from the “simple” to the “chaotic”. Taz explained that, for instance, you can add one server and it’s simple, two and it’s still simple, three and it’s still simple, but at some point you have 123 servers and it’s chaotic. Aha! This is how it happens that apparently “simple” techniques break down with size. You have 5 files in a folder and it’s simple; you keep adding files and suddenly it’s unmanageable. Another popular example: the easiest thing in the world is to solve a new requirement by adding a IF. You keep doing that, and you will end up with a tangle of spaghetti code. You must act in advance and start building appropriate structures: create methods and classes and packages; create appropriate subfolders; keep a journal of server deployments. Use whatever is appropriate. Techniques that seem “more complicated” when your situation is simple, become tools to conquer chaos when your situation is not simple anymore.

At the end of the day, Pierluigi asked the participants for some highlights of the day. The questions were “what was interesting? and how will you use it?”

After dinner I saw a bit of Pierluigi perform his coaching magic with Systemic constellations. How much there is to know!

That was not really the end, as I had a fun time with Sven, Jule, and the friends from Bologna playing Fluxx at the bar.

The next day started with Stefania hosting a session of Laughing Yoga. You can’t believe this, it’s amazing!!!

I hosted a session on Values, not requirements, where I argue some of the shortcomings of standard agile approaches to planning: functional requirements that are not real requirements, failure to identify what’s really important (a Value) for the stakeholders and failure to quantify it. It was a very short introduction to the techniques that Tom and Kay Gilb have been promoting for a very long time. See www.gilb.com or kickassproject.com for more information.

Pierluigi hosted Congruent Management. I’m a huge fan of Weinberg, who wrote books on congruent management, so I could not miss this. Pierluigi was approaching the subject from the perspective of Spiral Dynamics, that is a sophisticated model of how individuals and societies have different “levels of existence”. Pierluigi let us discover what sort of things people will say according to their level of existence, and let us think what we would do to motivate an individual, given that we think we recognize what level they are in. Powerful stuff! As long as you take it as an invitation to try to understand what goes on in the mind of the people around us, instead of an invitation to try to manipulate people. Of course Pierluigi wants us to do the former :-)

My last session was Object Thinking, the Lost Art. It was a lot of fun for me; I hope the people in the session had at least a small “aha!” It was the first time I used the CRC technique the way Kent & Ward say they were using it in their training, i.e. using people in place of cards :-)

It’s been a great (un)conference. Lots of energy from everyone; I arrived feeling tired and cranky, I came back feeling happy and energized. Good job, everybody!