Extreme Enthusiasm

A great many years ago I was fascinated by Bertrand Meyer’s book “Object Oriented Program Construction.” One of the many remarkable things in that book is the idea of “Design By Contract”, where you specify what a method does by means of a logical pre– and post–condicion. Consider the square root function:

  pre: x ≥ 0
  post: abs(y*y - x) < epsilon

This is a very good specification:

• It’s efficiently executable.
• The intent is clear.
• Gives no hint about how to implement it, i.e., it does not contain design ideas.

Now I’m reading the Scrumban book by Corey Ladas. One thing Corey says is that Test-Driven Development is good, but not as good as Design By Contract; in fact, he says, TDD might be a stepping stone to DBC.

(more…)

A dreary afternoon

A while ago I was in the office, while the team was busy programming. I heard one of the developers typing with some intensity, and puffing. “What are you working on?” — I asked. — “I’m working on this administration panel. And it’s darned tiresome work!!”

So I started observing him. (more…)

Ron Jeffries on the Software Craftmanship mailing list recently wrote this:

We write a test showing what we intend to accomplish, and a few
minutes later, we have accomplished it. If doing that has made the
design not quite as nice as it was before we started, we evolve the
design in place to keep it good.

The more we practice this, the easier it gets and the better we get
at it.

That said, there will always be times when our design ideas come too
late for immediate inclusion but they are still desirable to put
into the program. This is the original meaning of “technical debt”,
the deviation of the code now from what we understand of the
desirable design now.

I find it very clear… this explains that “technical debt” does not mean “code like hell, make a mess, hope for the best, we’ll fix it later…”. It means that, assuming I always write clean code, which means write as good code as I can, it can happen that I get an idea about how the code *should have been* organized. That may take days to do, so I don’t do it at once. It remains as a “debt” I will pay some day.

This also means that design debt is not immediately visible! It’s in the mind of people who worked for months with a project and finally got an insight. The kind of refactorings I suggested earlier might be an example of technical debt.

Again on the Kata Yahtzee, that I blogged about some time ago.

If you have not solved the kata at least once, please stop reading this! Get back when you have.

Good to see you again! Now that you solved it, you probably know that the naive solution takes many “for” loops. Let D be the player dice, represented as an array of die results, e.g., D=(1,6,1,6,4). The naive rules for sixes would be

    def sixes_score 
      sum = 0
      for d in D
        if d == 6
          sum += 6
        end
      end
      return sum
    end
  

This solution involves searching for sixes and adding up. Why do we need to search? We need to search because there are many different D that are worth exactly the same for the sixes rule. For instance, both D=(1,2,3,6,6) and D=(6,6,1,2,3) are worth 12.

(more…)

Some notes on what I took home from the Agile Coach Camp Italy 2011, that happened in a beautiful country resort in Umbria from 6 to 8 May.

The session “What is a coach” facilitated by Andrea Provaglio, for a sampling of how coaches think and what they do.

The session on “Agile ceremonies in distributed teams”, facilitated by Sven Tiffe, for tips and real-life tales.

The session “Coaching Dojo”, facilitated by Oana Juncu, where novice coaches practice problem solving by asking questions.

The session about ALE Italy, again by Andrea, where we shared ideas and vision about a shared idea of Agile and Lean in Europe. In particular the idea of sharing “Status of Agile in my Country” reports.

The session about Conceptualizations by Pierluigi Pugliese, that introduced some strategic-level models for deciding how and if to introduce change in an organization.

The session about “A3 Thinking” by Claudio Perrone, showing that problem solving is a structured activity that can be taught and learned.

The session “Becoming a Coach”, organized by Vittorio Scibetta, where accomplished coaches shared their thoughts on things that shaped their coaching and how to learn about coaching.

The coding dojo where Alberto Brandolini practiced the art of maintaining focus while a chattering crowd of “umarell” (*) was teasing and criticizing him!

Now it’s clear to me that being an agile coach involves more than knowing TDD. If you want to be an “agile coach”, there’s a lot to learn about the “coach” part in addition to the “agile” part.

This was the first “unconference” I attended. In this kind of conference, also known as an “open space”, the program is not prepared beforehand; rather, the organizers provide a structure, such as blank timetables, rooms and materials, and by a process called “marketplace” the participants prepare the program on the spot. It was great! I learned so much. In this case the openspace organizer was Pierluigi, who spent a lot of care and attention to detail to make it work smoothly.

I also was impressed by the good energy of participants; lots of games, laughs and smiles. It’s been a very good place to be.

(*) In Bologna, “umarell” is someone with time on his hands who watches workers in roadworks and offers criticism :-)