Wednesday, September 26, 2007 

Voyage in the Agile Memeplex

Voyage in the Agile Memeplex is an excellent article by Philippe Kruchten, featured in the July/August issue of ACM Queue. Luckily, the publishers decided to make it freely available.

I must confess that while reading the "Decontextualization" and "Agilese" paragraphs, I couldn't help thinking "hey, I can't remember when I wrote this article" :-).
Indeed, context has been a constant theme in my recent postings. To get a quick recap, I did a little digging and here are my most relevant context-aware :-)) posts, with short excerpts.

Overloading + Template = Reuse (August 09, 2005)
"Using scary formulas without a context"

Quadrants ( September 26, 2006)
"Following recipes (that includes TDD, Pair Programming, and whatever else if not carefully considered in context) just doesn't look agile (or plain old sensible ;-) to me."

Slip Charts ( November 14, 2006)
"but information without action is useless. Now, action is always context-dependent. For the real project above [...]"

Improving performances in C++ code (November 24, 2006)
"Decoupling is a good design principle. However, design is always contextual. Blindly following non-contextual design principles is a recipe for failure. "
"Following rigid guidelines, outside the problem context, makes a lot of critical thinking disappear, which may be good for your cognitive load :-) but not for the ultimate result"


Design for Outsourcing (April 11, 2007)
"countless pages have been spent in debates over the up-front Vs. as-you-go design approaches. What is often missing in most debates is context: quite often, there is some truth in both sides, that is, given the proper context, a given approach might be better suited. It's usually the (faulty) assumption that some approach can always be successfully adopted that makes so many debates futile."
"Design should be therefore discussed in-context. Context includes the technological issues, the market issues, the organizational issues, the human issues, and so on"
"In that particular context, what was missing offshore was domain knowledge, not programming knowledge"
"but as I said, design is contextual, we don't make choices in a void (this, again, is why I don't like frameworks that have made too many choices for me)."


GUI [Anti]Patterns and Safety-Critical Systems (April 24, 2007)
"there are quite a few interesting point in that paper on safety-critical systems. You will recognize the centrality of contextual design, as safety-critical systems may have to compromise on other important aspects (e.g. user productivity)."

Get the ball rolling, part 3 (of 4, pretty sure) (July 17, 2007)
"In the last few months I've been repeating a mantra (also in this blog): design is always highly contextual"

Get the ball rolling, part 4 (of 4, told ya :-) (August 04, 2007)
"In this context, the wise thing to do is write code first."
"Context is the key. Just as ignoring gravity ain't safe, ignoring context ain't agile."


Non-linearity, Modeling and Correctness by Design (September 04, 2007)
"Context-unaware suggestions like this are always short-sighted."
"Let's consider each one in context, as true agility cannot be achieved by applying cookbook recipes."


As you can see, the frequency is increasing among my 2007 posts, mostly as a reaction to the total lack of context in too much literature. So, I'm glad Philippe took the time to write so vehemently about it.

Of course, although he focuses quite a bit on agility, lack of context has plagued most of the pre-agile literature as well. Indeed, most of the pre-agile methodologists never spent too much time discussing their values, beliefs, and so on (their memeplex). A few old-timers (like Tom DeMarco, Michael Jackson, etc) always kept context in mind. Many others didn't.

However, to paraphrase Niklaus Wirth in my 1997 interview, in our maturing field, more attention to context should be considered not a dispensable luxury, but a simple necessity.

Labels:

Comments:
Thanks for this link! Maybe it's my new fatherhood or I might just be getting old but I agree on 98% of what Kruchten writes!! There are a few "misconceptions" but overall I agree.

From my point of view what he is talking about is the result of the "commercialization" of the Agile ideas. When big companies (e.g. Microsoft & IBM) start talking and selling "Something" products you can bet that that something is going to be watered down.

On one hand this is the fee to be paid for becoming mainstream, on the other hand it's the result of too many people jumping on the bandwagon: talking & writing about something they have a limited understanding and experience of.

I clearly remember the first discussions in 1999/2000 exactly about the importance of context and how and why you cannot just blindly follow a process and be successful because everything depends on the context. The phrase I used to use (and I still do) was "if you do XP/Scrum/Agile by the book you haven't understood the book!" ;-)

In mainstream agile this is getting lost. Does it mean that Agile pushes for decontextualization or that people who claim to "be Agile" are loosing a fundamental aspect of Agile? I vote for the latter :-)
 
In mainstream agile this is getting lost. Does it mean that Agile pushes for decontextualization or that people who claim to "be Agile" are loosing a fundamental aspect of Agile? I vote for the latter :-)

Me too (maybe surprisingly? :-))

Hey daddy :-), nice to hear from you again!
 
Thanks! :-)

I'm sorry I didn't find the time to read thoroughly (and possibly comment) your previous posts about agile. I'm on a 2-month long leave of absence because of the baby (but will be back to work next week). Great food for thought though
 
morning addenda
while I totally agree about the "loosing a fundamental aspect of Agile" part, I'm not really convinced the culprit stands on the big corporations side (although they do make for an easy target :-).

I would say it's partially because of the overnight converts (I could provide famous names but I won't :-) more concerned with the right message to sell books and seminars than with the Right Message.

There is also an interesting theory, which applies to each and every [process] innovation. Unfortunately, I can't remember who got the idea, but it goes something like this: every innovation is successful, at first. That's because the early adopters happen to be highly skilled, highly motivated people, working in an innovative environment. When the "innovation" becomes mainstream, it has to face the general population, and boys do things change.
I guess I first heard the theory from someone talking about the apparent "failure" of OOP, and although it's slightly too pessimistic for my taste, there is certainly some truth behind it...
 
Absolutely. The big corporations thing wasn't really about themselves but about the fact that it can thus be considered mainstream and to be mainstream things "have to" be watered down. OOP was something I was going to write about in my first comment as another example.
 
Caro Carlo,
ho una domanda un poco provocatoria per chi come te ama riflettere in profondita' sulle metodologie.
Premesso che come formazione intellettuale personale sono uno strenuo seguace di Popper, e premesso anche che la metodologia dell'indagine scientifiche si discosta molto da TUTTE le metodogie ingegneristiche, vorrei porti una domanda un poco provocatoria.
Quello che mi "disturba" di tutte le varie metodologie per lo sviluppo del software e' la mancanza di un chiaro "criterio di demarcazione": ovvero un criterio preciso per affermare se si e' "dentro" o "fuori" una determinata metodologia di sviluppo.
La mia domanda e': tu pensi che sia possibile IN ASSOLUTO trovare un simile criterio di demarcazione per una QUALUNQUE metodologia di sviluppo? (Potremmo prendere come esempio proprio il tuo Systematic OO Design, se ti va!)

Un affettuoso saluto
Guido Marongiu
 
Piu' che provocatoria e' difficilissima :-).

L'ambiguita' inizia gia' con la definizione di metodo / metodologia. Provando, in modo piuttosto soggettivo, a decomporre analiticamente un metodo di sviluppo software, direi che al suo interno troviamo (riprendo alcuni argomenti gia' discussi in passato)
- dei valori, cose che si ritengono positive / negative
- dei belief, cose che si ritengono vere
- delle pratiche, cose che facciamo assumendo che i nostri belief siano per l'appunto veri, e che dovrebbero portarci a rispettare i valori positivi che proponiamo, e ad evitare/mitigare i valori negativi.

Supponiamo che questa mia definizione un po' estemporanea sia sensata. Allora la tua domanda si puo' riprendere alla luce della suddivisione di cui sopra, e la cosa diventa un poco piu' semplice (soprattutto partendo dal fondo).

a) esiste un modo oggettivo (rifraso cosi' il tuo "in assoluto" sperando di averne colto il senso) di dire o meno se una pratica viene seguita?
Dipende ovviamente dalla chiarezza con cui la pratica viene documentata, ma in generale risponderei si. E' facile dire se stiamo adottando o meno pratiche come pair programming, visual modeling, refactoring, continuous integration, branching & version control, ecc. Per metodi che sono practice-intensive, come il SysOOD, questo si avvicina abbastanza a dire se stiamo o meno adottando il metodo, anche se ovviamente non e' proprio la stessa cosa.
[Anche in questo caso, alcune pratiche non vengono ben definite ed e' pertanto difficile dare un criterio netto. "upfront design", ad esempio, non e' chiarissimo cosa significhi. Se penso 10 secondi prima di scrivere la prima riga di codice, ho fatto upfront design? In questo senso, quel tipo di nomenclatura allontana da una visione "oggettiva" (non voglio dire "scientifica")].

b) esiste un modo oggettivo per dire se sposiamo o meno i belief ed i valori di un metodo? Per quanto mi riguarda, in generale, no. E' un mondo troppo sfumato, troppo soggettivo, troppo implicito (nel senso di conoscenza che non si riesce a verbalizzare, che si trasmette bene solo con l'esempio, my life is my message ecc ecc :-).
Ovviamente, il fatto che non esista un modo oggettivo di dire in generale se sposiamo o meno [tutti] i belief ed i valori di un metodo, non significa che non si possa fare, qualche volta, sul singolo elemento. La fregatura (qui entra in ballo il contesto) e' che value e belief vengono spesso espressi in modo conciso eliminando il contesto. Questo e' sbagliato, perche' io magari condivido un belief in un certo contesto, ma non in un altro. Persino sui valori, che tendono ad essere piu' context-independent, si trovano situazioni in cui il contesto porta a sposare un valore piuttosto che un altro.

Detto tutto cio', stendere un elenco dettagliato di values, beliefs and techniques dovrebbe ormai essere un requisito di ogni metodo. Anzi, per quanto riguarda i primi due, anche di un colloquio di assunzione :-)). Cosi' come la chiara esposizione dei contesti in cui si ritiene praticabile cio' che si professa...
 
mi fai un esempio di valore e uno di belief?
 
Questo e' relativamente facile e quindi rispondo in fretta :-)).

Siccome tutto e' nato da un articolo che parlava di agility, mi rifaccio a Principles behind the Agile Manifesto. Citazioni in italico.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Questo e' un belief. Qualcosa che assumono essere vero. E' peraltro qualcosa che tendo a condividere in molti casi, ma tanto per chiudere il cerchio, e' uno di quei "contextual belief" di cui parlavo. Ci sono diverse situazioni in cui non e' vero.

The best architectures, requirements, and designs emerge from self-organizing teams.
Questo e' nuovamente un belief. Uno, peraltro, particolarmente discutibile :-), soprattutto se definito in forma cosi' decontestualizzata.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Questo e' un valore. Un valore che personalmente condivido, anche se comprendo l'occasionale necessita' di andare in crunch mode. Un valore che invece in molte aziende viene ordinariamente calpestato, per un misto di incapacita' manageriale, business model desueto, mentalita' retrograda da aziende nate come piccolo-padronali, ecc. Non e' un belief, nel senso che non e' qualcosa che si ritiene vero, ma qualcosa che si vuole raggiungere, qualcosa che si ritiene positivo.

Altre "principi" nello stesso documento sono meno clearcut, sono un miscuglio di value e belief (anzi qua e la' si possono intravedere delle pratiche che tentano di fare capolino). Ora, scritti in quel modo, magari suonano anche poetici :-), ma a mio avviso sarebbe meglio privilegiare la chiarezza di intenti piuttosto che il linguaggio aulico. Per chi ne ha voglia, l'esegesi del testo rimanente e' lasciata come mitico/mitologico "esercizio per il lettore" :-).
 
Post a Comment

<< Home