Extreme Enthusiasm

This speaks to a very important, in fact, vital understanding that students must have, and it is this: a great many of the teachers of guitar, and a great number of all instructional materials out there, are only useful if you already know certain things, or already have overcome or bypassed certain obstacles. Otherwise, these teachers and instructional materials are actually harmful, they will increase your problems, and, if followed over time, will ingrain those problems more completely into your technique.

Wow. I found this quote in today’s newsletter from Jamie Andreas. I gave up guitar long ago, but I still subscribe to her newsletter because she’s a very good teacher. Let me repeat: she’s a very good teacher. She really cares about how to get to mastery.

Now is this relevant to XP and agile? You bet! The bitter truth I learned is that going head on for XP with TDD and incremental design might not work well, unless the team has a solid enough grasp of the basics of software design. The authors of the Grand Old XP Books were raised in a primordial broth of object-oriented design; they lived and breathed it. Not so for the kids these days: OOD is not fashionable. All we hear and care about is tools and frameworks.

The advice in Rapid Development is always sound: work on the fundamentals!

Summary: looking for developers for my current project.

Come penso sappiate lavoro per XPeppers, una piccola azienda dedicata allo sviluppo software tramite Extreme Programming. In questo momento abbiamo un grosso progetto appena partito e cerchiamo persone per rimpolpare il team. Le posizioni che cerchiamo sono permanenti.

Gli sviluppatori che cerchiamo lavoreranno nel mio team, a contatto con me. Il progetto in questione è un’interessante applicazione Java; ma non la tipica applicazione Java “enterprise”: non usiamo Spring e non usiamo Hibernate. E non usiamo Maven! Di Java Enterprise tutto quello che usiamo per il momento è una servlet e l’interfaccia JDBC. Per il momento sta funzionando bene; non abbiamo praticamente mai avuto sviluppatori bloccati a cercare di capire perché le configurazioni non funzionano :-)

Tutti i dettagli sono su http://www.xpeppers.com/carriere/

We always speak of “agile methods”, implying that there is more than one…. actually, 99% of the times, when we talk about agile methods we mean either Scrum or Extreme Programming. There are other agile methods however, and one you don’t get to hear about too often is Evo, the method that Tom and Kai Gilb invented.

In my presentation at Better Software in Florence I talked about how Gilb made me think again about how to plan and organize a software development project. Well actually not just software development, as the principles can be applied to projects of all kinds.

Please find the slides below. (In Italian).

I just uploaded my slides for the presentation I had the pleasure to give at the Italian Ruby Day last Friday.

Comments welcome :)

This is a preview of my upcoming presentation at the Italian Ruby Day, in Milano on June 10.

Kent Beck wrote in Smalltalk Best Practice Patterns:

There are a few things I look for that are good predictors of whether a project is in good shape. These are also properties I strive for in my code.

Once and only once – If I only have one minute to describe good style, I reduce it to a simple rule: in a program written with good style everything is said once and only once. This isn’t much help in creating good code, but it’s a darned good analytic tool. If I see several methods with the same logic, or several objects with the same methods, or several systems with similar objects, I know this rule isn’t satisfied. This leads us to the second property:

Lots of little pieces – Good code invariably has small methods and small objects. Only by factoring the system into many small pieces of state and function can you hope to satisfy the “once and only once” rule. I get lots of resistance to this idea, especially from experienced developers, but no one thing I do to systems provides as much help as breaking it into more pieces. When you are doing this, however, you must always be certain that you communicate the big picture effectively. Otherwise, you’ll find yourself in a big bowl of “Pasta a la Smalltalk”, which is every bit as nasty a dish as “Fettucine a la C”.

Replacing objects – Good style leads to easily replaceable objects. In a really good system, every time the user says “I want to do this radically different thing,” the developer says, “Oh, I’ll have to make a new kind of X and plug it in.” When you can extend a system solely by adding new objects without modifying any existing objects, then you have a system that is flexible and cheap to maintain. You can’t do this if you don’t have lots of little pieces.

…

I like this description of Kent’s. I think this explains well something important, that many people miss when they start doing Agile programming. (That includes me :-) The original XP books somehow imply that the reader agrees with the above. That’s because these principles are a key to write code that’s easy to change.

“Lots of little pieces” and “Replacing objects” are particularly interesting. They agree with the Open-Closed Principle. They mean that the code should grow preferably by generating new objects, not by adding code to existing objects. (See also this post by Michael Feathers.)

Now take a look at Rails applications. How do they fare with respect to the above principles? Now, Once-and-only-once has always been a Rails battle cry. But what about “Lots of little pieces”? With Rails, everything is centered around database tables. You can reconstruct the logic of a Rails application by starting with the Entity-Relationship model. For every entity you have a Model class, then probably a Controller class, its Helper module, and a number of Views. In most cases, the Model and Controller classes will be modified all the time during the evolution of the application. This is in contrast to the Open-Closed Principle. In other words, it’s not obvious how to express a Rails model as a composition of simpler objects that are reused across the application.

There are (relatively) well-known Rails techniques for reducing the size of controllers. But the consensus advice of aiming for skinny controllers, fat model leaves us with the problem of the fat models. There is no obvious, well known technique for solving this problem systematically.

In my presentation at Ruby Day I will suggest a few ways you could deal with this problem. I will talk about the main techniques for breaking up things in small pieces at the view, controller and model level. I don’t claim I have *the* solution; I have a few ideas that work. Some are from the Rails Antipatterns book, some are from my own experience working with Rails. Some are a bit unconventional :-)

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.

Read the rest of this entry »

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. Read the rest of this entry »

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.

Read the rest of this entry »

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 :-)