Extreme Enthusiasm

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!

Two months ago I re-started a freelance career. Now I have a new coaching engagement that I’m very happy about. One interesting thing that I learned in the past few weeks is that I had a fundamental misconception about the idea of velocity. I think that this misconception is common, so I will tell you about it.

You know what velocity is: it’s a very important number that measures how much a team has accomplished in the past iterations. When an iteration is finished, you add up the estimates of all the user stories that are done-done. That is your velocity.

There is a common misconception about velocity, that it can be used to compare teams or to reward/punish the team. This is a well-known and well-documented error, because doing so will push the team to game the metric and destroy its usefulness.

But it is not that error I want to talk about; it’s a more subtle one. You know, ever since I learned about XP, I always thought that the goal of an XP team is to maximize velocity. That is, to deliver as much as possible, while keeping the system clean and well tested and so on.

This is an error. You don’t want to maximize velocity. Your goal is to stabilize velocity. What you want is to deliver about the same velocity in each iteration; and the way to obtain this is to add slack; make sure that if the estimates are correct, you will end the iteration with ample extra time. The team will *not* use the extra time to deliver one more story; they will use it to reduce technical debt, to clean the system, to improve the tests, to study, to perform technical improvements, and so on.

This is a very counter-intuitive thing, yet I now understand that if you don’t use slack to keep the velocity stable, it’s very difficult to achieve the goal of keeping the cost of change down. Thanks to James Shore for the video of his presentation We Deliver Business Value at the NDC2011 conference. The concept is also well explained in Shore and Warden’s book.

Another quote:

The Product Owners look at slack as a way to evaluate whether the team is overloaded–and seek to reduce velocity until we hit slack consistently. Otherwise, we fear we’ll be paying for code debt, bug fixes, and reduced innovation that the team can’t really see until they come up for air.
André Dhondt

Also, a fundamental principle in Lean is that before you try to optimize you should stabilize: reduce variation in the output.

Now you know it!

I read this in Mark Seemann’s blog:

Most of the classic design patterns are based upon the idea of programming to an interface instead of a concrete class. In OOD, it’s necessary to point this out as a piece of explicit advice because the default in OOD is to program against a concrete class.

That’s not the case in FP because functions can be composed as long as their signatures are compatible. Loose coupling is, so to speak, baked into the paradigm.

This is nonsense. The fact that functions can be composed as long as their signatures are compatible does not imply that the functions you compose are loosely coupled. In FP you can easily write functions that depend on the concrete way that information is represented. Changes in how a function returns data may break other functions down the road. I would say that in fact the opposite is true: the main danger of FP is that concrete representations are passed around all the time. At least this much can be said about OO, that OO pushes towards encapsulation of data representations. This is “baked into” the OO paradigm.

Look, I fully agree that FP is great. But how much of this new enthusiasm for FP is due to FP being a new thing (at least to these new converts?) People trying FP now did not have the time to write spectacularly bad systems with FP. Yet. Then what? We’ll be praising Logic Programming over FP? Me, I’d rather spend my time learning to use one paradigm *well*.

I published the slides from my Object Thinking presentation at Codemotion 2012… in Italian.

Update: Here is the video (in Italian)

One year ago I wrote What have I been up to?. I told the story of how we fixed a flaky application. A few months later, the same customer contracted me and our team to rewrite the whole application from scratch.

That was a big job! It lasted from early July to the end of March. All the members of the Orione Team in Milano were involved, with a contractor from Cagliari and one from Rome. About 8-9 people from XPeppers and 3 more from the customer. I’m happy to report that we delivered the system, essentially on time and on budget and with a happy customer.

How did we do that? I’m thinking about writing a longer article on that. There are many ingredients. Some of the most important are heavy customer involvement, incremental delivery, test-driven development and automated acceptance tests. But really, it’s about people and focus.

And now… a change of horizons. I’ve been working in Sourcesense first and XPeppers later for 5 years. The Orione team was formed about 4.5 years ago and I’ve been with them for all this time. I don’t think I can give them anything more. I feel it’s time for a change. I’m going back to being an independent coach and consultant. Wish me luck!

And contact me if you think I can help you.

The book Object Thinking makes a very good explanation of the divide between two different, antagonistic modes of thinking. The formalist tradition (in software) values logic and mathematics as design tools. A formalist thinks that documents have objective, intrinsic meaning. Think “design documents”; think “specifications”.

The empirical tradition (the book calls it hermeneutics, but I will stick to this less formal name :-) values experimentation. Empiricists hold that the meaning of a document is a shared, temporary convention between the author and the readers. Think “user story”; think CRC cards; think “quick design session on the whiteboard.”

The empiriricists brought us Lisp; the formalists brought us Haskell. The formalists brought us Algol, Pascal, Ada. The empiricists brought us C, Perl, Smalltalk.

Empiricists like to explain things with anthropomorphism: “this object knows this and wants to talk to that other object…” The formalists detest anthropomorphism; see these quotes from Dijkstra.

As a former minor student of the best formalist tradition there is, and a current student of the Object Thinking tradition, I think I’m qualified to comment. Please don’t take my notes as meaning that the formalist tradition sucks; I certainly don’t think this. I’m interested in highlighting differences. I think a good developer should learn from both schools.

Formalists aim to bring clarity of thought by leveraging mathematical thinking.

Object thinking aims to bring clarity of thought by leveraging spatial reasoning, metaphor, intuition, and other modes of thinking.

It is well known that mathematical thinking is powerful. It’s also more difficult to learn and use. One example that was a favourite of Dijkstra is the problem of covering a chessboard with dominoes when the opposite corners of the chessboards were removed. If we try to prove that it’s impossible by “trying” to do it or simulating it, we’d quickly get bogged down. On the other hand, there’s a very simple and nice proof that shows that it’s impossible. Once you get that idea, you have power :-)

An even more striking example is in this note from Dijkstra on the proof method called “pigeonhole principle”. Dijkstra finds that the name “pigeon-hole principle” is unfortunate, as is the idea to imagine “holes” and a process of filling them with “pigeons” until you find that some pigeon has no hole. The process is vivid and easy to understand; yet it is limiting. Dijkstra shows in this note how to define the principle in a more simple and powerful way:

For a non-empty, finite bag of numbers, the maximum value is at least the average value.

This formulation is simple (but not easy!) Armed with this formulation, Dijkstra explains how he used this principle to solve on the spot a combinatorial problem about Totocalcio that a collegue of his could not solve with pen and paper. He also explains how he used it to solve a generalization of the problem, which would not be easy to prove with the “object-oriented” version of the principle.

I think this note presents the contrast between formalism and empiricism vividly. If you put in the effort to internalize the formal tool, that which was difficult becomes easy, and you can solve a whole new level of problems.

On the other hand, the formalists do now always win :-) Formalists reject the idea of making tests the cornerstone of software development. In my opinion they are squarely wrong; examples are the primary tools to do software development, and you can’t even understand if a specification is correct until you *test* it with examples.

The one thing that boths camps have in common is that they are both minority arts. Real OOP is almost as rare as Dijkstra-style program derivation. The common industrial practice is whateverism :-)

Some people like Carlo say that the famous Four Elements of Simple Design by Kent Beck are an oversimplification. Perhaps it’s true, but still I find that they are a very useful compass. Consider again:

A design is simple when

1. Runs all the tests.
2. Contains no duplication
3. Expresses all the ideas you want to express.
4. Minimizes classes and methods

in this order.

Rule 2 is important, as it pushes us to invent abstractions that capture recurring patterns. But rule 3 is also imporant, as it pushes us to invent abstractions that correspond to the ideas that we want to express.

The other day I saw this post by Luca about a fun kata: implementing the scoring rules for a dice game called “Greed”. This exercise is part of the Ruby Koans, but its use as a programming exercise dates at least from the OOPSLA ’89 conference, when Tom Love proposed a contest to show how a program could be written in different ways and in different languages.

A little research shows many solutions for this problem. As this problem is presented in the context of a Ruby programming exercise, people usually tries clever tricks that exploit peculiar Ruby idioms. For instance:

def score(dice)
  (1..6).collect do |roll|
    roll_count = dice.count(roll)
    case roll
      when 1 : 1000 * (roll_count / 3) + 100 * (roll_count % 3)
      when 5 : 500 * (roll_count / 3) + 50 * (roll_count % 3)
      else 100 * roll * (roll_count / 3)
    end
  end.reduce(0) {|sum, n| sum + n}
end    

http://stackoverflow.com/a/6742129/164802

There’s a place for this sort of exercises, but it’s not the sort of programming that I would like my collegues to practice! If we apply the rule 3, I expect to see in the source cose some mention of the *rules* of the game. I expect that there’s a programming element that corresponds to the rule that “three ones are worth 1000 points”, etc. Really, it does not take all that much more effort, and I assert that it’s more fun to code expressively!

This is my solution:

class Array
  def occurrences_of(match)
    self.select{ |number| match == number }.size
  end

  def delete_one(match)
    for i in (0..size)
      if match == self[i]
        self.delete_at(i)
        return
      end
    end
  end
end

def single_die_rule(match, score, dice)
  dice.occurrences_of(match) * score
end

def triple_rule(match, score, dice)
  return 0 if dice.occurrences_of(match) < 3
  3.times { dice.delete_one match }
  score
end

def score(dice)
  triple_rule(1, 1000, dice) +
  triple_rule(2, 200, dice) +
  triple_rule(3, 300, dice) +
  triple_rule(4, 400, dice) +
  triple_rule(5, 500, dice) +
  triple_rule(6, 600, dice) +
  single_die_rule(1, 100, dice) +
  single_die_rule(5, 50, dice)
end  

There's some more duplication that could be removed (the five similar rules could be expressed as a single rule) and the names could be improved, but I think this is the way to go. Make your code look like a model of the problem!

I have a feeling for classes that should not be there. When I saw this cartoon about “how an object-oriented programmer sees the world”, I was struck by the fact that all the names of objects were wrong! These are the names that would be chosen by a poor OO programmer. A good programmer would choose “Door” instead of “IndoorSessionInitializer”. But then the cartoon would not be funny :-)

A similar thing happens in the code base of our current project. Sometimes I see a class that strikes me as odd. Perhaps it has a name that does not communicate; more often it is simply a class that should not exist.

Read the rest of this entry »

Object-Oriented decomposition is supposed to be different

When I read Object Thinking, I was intrigued by this quote by Grady Booch:

Let there be no doubt that object-oriented design is fundamentally different from traditional structured design approaches: it requires a different way of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structured design culture.

So it seems that OOD decomposes a problem in a way that is essentially different from what you would arrive at with other design methods. I was intrigued: I wonder what are these different, elusive ways of decomposing things.

Read the rest of this entry »

A revelation inside another revelation

I’ve been reading Object Thinking. It’s an unusual book, in that it talks mainly about the philosophy of OOP rather than technicalities like Dependency Injection. There are many gems in this book. One of the main things I got out of it is that Object Thinking is a revolutionary break with respect to established software engineering practice. Another thing is that the view of objects as Abstract Data Type is basically the establishment’s way to dilute and incorporate the grand new thing and make it look like a variation of the old thing.

Again, one thing that I changed my mind about is to take seriously the idea of modeling the domain. I mean, the old OOP books all said things like “take the description of your problem, underline the nouns in the description, and these are your candidate objects”. I used to think that this is a silly exercise! And I’m not alone. I heard many times the phrase: “objects are good, but not for the domain.”

In the last few years since I attended Francesco Cirillo‘s workshop on Emergent Design in 2009, I have been studying OOP. I learned about the GOF patterns. I learned about the SOLID principles. I learned how to write testable code. I learned how to do TDD for the infrastructure. I learned how to test-drive Chicago style and London style. I invented exercises for teaching the Hexagonal Architecture and the Open/Closed principle.

All of these things are good, and very useful to learn. Yet they are not the heart of Object Thinking. All these things are based on the shape of programs. For instance: I write a Long Method (bad), then I Extract Method a few times, then I Extract Class, and voila, I have done an Object Decomposition. But this is a mechanical exercise, that takes into account mostly the shape of the methods and not their meaning. If I’m lucky, my decomposed class will turn out to be something significant in terms of the domain. If I’m less lucky, I’ll have extracted some boring bit of infrastructure, like the IndoorSessionInitializer.

What I was missing on is decomposition based on Object Thinking. Decomposition based on writing the Domain Model. Thinking about the Domain Model as a simulation of the problem domain, as if the domain objects were little computer people sending messages to each other. Ding!

The incredible compressing brain of Kent Beck

Kent Beck’s brain contains probably the most efficient compression algorithm ever. Kent is able to compress in a couple of lines what others do take volumes to explain. Take Kent Beck’s four rules of simple design:

The right design for the software at any given time is the one that

1. Runs all the tests.
2. Has no duplicated logic. […]
3. States every intention important to the programmers.
4. Has the fewest possible classes and methods.

Kent Beck, Extreme Programming Explained

Consider item 2. It basically means: look at the shape of your code, and wherever you see the same information encoded twice, find a way to generalize or abstract so that it is encoded just once. In a few words he is implying the contents of the Refactoring book, of SOLID, and all approaches that look at the shape of code for guidance on how to improve its design.

Then consider item 3. It basically means: look at the meaning of your code, and make sure that the meaning is apparent in the names and the structure. This implies that you should make your code a model of the problem domain.

(Items 1 and 4 are just safeguards against making refactorings that break functionality, or going wild with OOD ideas and making the design worse by making it overcomplicated.)

Am I crazy or…

As an aside, I find myself buying lots of out-of-print books. It seems the things that I find most interesting are not what the world of programming in general finds interesting. Even my beloved Extreme Programming seems out of fashion lately. Nobody wrote about XP since Kent Beck wrote the last of the Coloured Books in 2004. But I still think that OOP and evolutionary design and XP are crucial things to learn. Yet everyone wants to learn about the latest technology fad. The latest technology fad I’m getting into is SmallTalk, and it’s something that stopped being developed around 1980. This means that either I’m crazy, or everyone else is.

In conclusion

When I was young I really believed in objects. My first falling in love with objects was over the cover of an issue of Byte Magazine dedicated to OOP.

I remember now that in nineteen-eighty-something I wrote an object-oriented program for an AI assignment. It was a program for symbolic integration that took inspiration from some crazy idea by Douglas Hofstadter. It was a community of software agents, each one specialized in some symbolic solution technique, that worked at the problem without any central coordination. It was written in some variant of Lisp that had no Object-Oriented extensions; so I wrote my own OOP system on top of Lisp. It was fun :-) and it was not difficult at all to do.

Then, in the nineties, I got enamored of formalist thinking; not the brand that did UML, but the brand that did Formal Methods. By then, OOP seemed such a scruffy and ineffective thing to me. But by that time, when I thought of OOP I was thinking of C++; I was thinking of large, unwieldy frameworks based on very long inheritance chains. Small wonder that I didn’t like it.

In the eighties, when I thought of objects, I thought of letting artificial intelligence emerge out of the collaboration of many simple autonomous agents. What a silly and romantic idea! Yet this idea is at the heart of OOP as was originally imagined by Alan Kay and the others.

This is probably a good place to comment on the difference between what we thought of as OOP-style and the superficial encapsulation called “abstract data types” that was just starting to be investigated in academic circles. … To put it mildly, we were quite amazed at this, since to us, what Simula had whispered was something much stronger than simply reimplementing a weak and ad hoc idea. What I got from Simula was that you could now replace bindings and assignment with goals. … the objects should be presented as sites of higher level behaviors more appropriate for use as dynamic components.
Alan Kay, The Early History of SmallTalk