Extreme Enthusiasm

I attended an interesting talk the other night at the Milano XP User Group. Uberto Barbini was sharing his thoughts and experiences over using Object-Oriented and Functional Programming together.

Uberto showed us some production code, that he thought was a neat application of FP in a OOP context. The funny thing is that to my eyes it seemed that was neither FP nor OOP; it seemed procedural to me. Uberto argued that it was functional and not procedural, because there was no global state involved; it was a self-contained transformation of data.

That got me thinking. Do I like that definition of “procedural”? I don’t think so. I think that you can tell procedural code when the thinking that goes behind that code is something like:

First I do this.
Then I do that.
If Zot Then I do Blah.
Else I do Blorgh.

When you think of a recipe, or a sequence of steps, then for me it’s procedural. Essentially “procedural” is to model the solution as a process.

On the other hand, functional programming, in my humble opinion, is about mathematical models. You model the problem and the solution with functions, sets, maps, trees and all those abstract and precise mathematical concepts.

What about Object-Oriented Programming then? My thinking about OOP has been in the past that OOP is a natural consequence of writing modular programs. An object is a hidden data structure with a visible collection of operations. Then I understood that this is just one way to look at OOP, and probably it’s the wrong one :-) This point of view is heavily influenced by mathematics (the idea that the operation on an object define a sort of algebra) and by procedural thinking (the idea that programs = data + procedures, just like the title of an old favourite textbook.)

I learned from reading GOOS that OOP is mostly about the messages. There are some intesting and tantalizing quotes from Alan Kay about that. Even more recently I read Object Thinking, and I came to understand that OOP is about modeling the problem with a community of autonomous agents. The way to make OOP shine is to build a simulation of the problem. And I remembered the thrill I once had when I first read about OOP. About imagining these little software robots going about their business inside my programs. An object that can “think” for itself and has a behaviour. Now *that* is what OOP is about!

Back to the original theme, now was the code that Uberto showed to us OOP, FP or procedural? It turns out that it depends! You can’t say by just looking at the code. It depends on the thinking that goes behind the code. Uberto thinks functionally when he thinks about this code. That makes it functional code for him.

Suppose that years later I inherit his codebase. If I have no access to Uberto, it’s pretty difficult for me to reconstruct his mental process. I will probably treat the code as procedural; or maybe OO depending on my way of thinking about this code.

So this is a pretty shocking thought, isn’t it? I thought you could look at a program and tell its paradigm, functional or procedural or OO, just by looking at the code. But I now think you can’t; the three paradigms are not different ways to code; they are different ways of thinking! Procedural thinking is about recipes: follow these steps. Functional thinking is about math: functions and sets. Object-Oriented is about simulations: many independent agents. And this explains why it’s difficult to do OO well. You have to learn a different way of thinking. This is something that I heard Francesco Cirillo say many times. Now I understand it a bit better :-)

Francesco Cirillo ha presentato questa sessione sabato scorso all’Italian Agile Day. Ho letto su http://joind.in/talk/view/4508 diversi commenti che non mi tornavano; allora ho scritto questa mia personale esegesi, perché penso che il messaggio di FC sia molto importante e mi secca vedere che viene spesso frainteso.

Quindi vi do la mia personale interpretazione, senza pretendere di parlare per Francesco. Fatto: se proviamo a leggere un qualsiasi libro in tema Metodi Agili, si dà per assodato che usando i Metodi Agili si diventa più bravi.

La realtà dei fatti, che ho personalmente riscontrato nelle mie esperienze, è che spesso questo non è vero. Diversi team agili di mia conoscenza hanno fallito progetti, o comunque hanno conseguito una fama di essere troppo cari. Fama immeritata? Che importa! Se il risultato finale è che il cliente non ti sceglie più hai fallito. E poi è facile che la fama non sia poi così immeritata.

E’ vero che molte pratiche agili producono un beneficio immediato; quel problema che facevi fatica a debuggare si risolve brillantemente con gli unit test, la comunicazione con il cliente migliora se andiamo a chiedergli che cosa pensa veramente, ecc. ecc. Ma c’è un grosso MA. Ci vuole molta, molta fatica per rendere questi benefici permanenti. E’ sulla distanza che si vede la differenza.

Tanti che credono di programmare a oggetti scrivono invece codice procedurale, e la differenza sulla distanza si traduce in codice ingarbugliato. Tanti che si rifiutano di fare big design upfront, non hanno capito che devono fare invece tanto design in maniera continua. E magari non sarebbero in grado di farlo neanche se volessero, il design upfront, né big né small. E poi, ci vuole tanto coraggio per continuare a mantenere un vero contatto con il cliente nel lungo periodo.

Kent Beck ha detto “What does it mean to be agile? My definition is that you accept input from reality and you respond to it”. Allora facciamola per davvero questa follia di accettare l’input dalla realtà! Misuriamo quanto ci costa sviluppare. E’ da qui che si vede se quello che facciamo funziona veramente.

E già che ci siamo, da quanto tempo non andiamo dal cliente a chiedergli “sei contento di come lavoriamo?”

Update 2011/12/11: updated link to HD video

Sessions are the Achilles heel of every application server.
Michael T. Nygard, Trampled By Your Own Customers (pdf)

Earlier this year I started a big Java development project with my team. I did mostly Rails development for a long time, so when I came back to Web applications in Java I had some expectations. I expected that Tomcat would treat user sessions in much the same way as Rails does; but it doesn’t.

(more…)

I’d like to share this quote from E.W.Dijkstra:

When the design of the THE Multiprogramming System neared its completion the University’s EL X8 was getting installed, but it had not been paid yet, and we hardly had access to it because the manufacturer had to put it to the disposal of an American software house that was supposed to write a COBOL implementation for the EL X8. They were program testing all the time, and we let it be known that if occasionally we could have the virgin machine for a few minutes, we would appreciate it. They were nice guys, and a few times per week we would get an opportunity for our next test run. We would enter the machine room with a small roll of punched paper tape, and a few minutes later we would leave the machine room with the output we wanted. I remember it vividly because when they realized what we were achieving, our minimal usage of the machine became more and more frustrating for them. I don’t think their COBOL implementation was ever completed.
EWD1303, My recollections of operating systems design

I can picture Dijkstra and his collegues working with paper and blackboards and thinking hard about how they were writing their software. They came into the room and their software just worked. And I can picture the Cobol crew in a furious vicious circle of code-and-fix; their growing frustration and despair. That was about 1960: no books on software design existed back then. For that matter, no books on compiler writing existed either.

Could the Cobol crew have done better? Absolutely. In 1954, the FORTRAN team led by John Backus produced a compiler that reportedly wrote code almost as good as hand-written. How could the poor Cobol crew have done something as good or at least good enough?

My answer: by designing their software. By breaking the thing into parts (modules) and developing each one separately. By using analogies from other engineering disciplines; by using metaphors. I know this is all obvious to us in 2011 as we all know about module decomposition and the use of metaphors and coupling and cohesion. But is it really obvious? Really?

What I see is that modern-day software teams today can *still* be divided in two kinds: the Dijkstra-crew kind and the Cobol-crew kind. Those who are in control and produce reasonably good software within reasonable resources and whose code is reasonably clean; and those who toil away late hours and produce late and buggy software, with no design, or perhaps with an ineffective, we-dont-really-believe-in-it design and crappy code.

Which do you want to be? What will you do to become it?

Great post:

http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours

Re-reading Kent Beck’s TDD book, Ian Cooper recovers some important things that are often overlooked.

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 here.

Update Here is the video

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