Skip to content

The Frog and the Octopus go to Snowbird

February 10, 2011

On February 11, the Frog and the Octopus will go to a celebration of the 10 years of the agile manifesto. As usual the Frog will remind everyone it can connect with that all software development projects are fundamentally the same, so there no need to get too excited about revolutionary new approaches, while again and again the Octopus will continue to say “all wrong, froggy, it all depends; it depends on the context, the context, the context!”:


Title: the frog and the octopus

… on their way

The frog’s view point (=the elements that are common across all software projects I know).

Conceptual model of software project management: commonality

Conceptual model of software project management: commonality

See more in this Frog’s point: conceptual model

The octopus’s viewpoint (the contextual factors that make the spectrum of software projects so vast and interesting):

Contextual model of software project management: variability, context

Contextual model of software project management: variability, context

See more here: Contextualizing software development

And in summary: we need both to really understand software development project.

the two parts of the  conceptual model

Note: we love to eat frogs and octopus. The ultimate fusion between French and Japanese food.

Technical Debt – Workshop, paper, game, presentation

November 20, 2010

News: 2nd Technical debt workshop in May in Honolulu…
ICSE 2011
Every software guru out there has now a blog entry on Technical Debt, so why not me? I will not repeat the basics, which are repeated everywhere and, which you can get from the masters, in particular:

Technical debt is more a rhetorical concept than a technical, scientific or ontological concept, but it seems to resonate well with the software development community, sometimes with managers and business people.

From a scientific viewpoint, we know little about technical debt. I take part in a little research project sponsored by the Software Engineering Institute (SEI), with colleagues Ipek Ozkaya, Rod Nord and Nanette Brown to investigate technical debt.

  1. As part of that effort we have organized a workshop on technical debt on June 2-3, 2010 in Pittsburgh,
  2. The results of this workshop are consigned in the paper “Managing Technical Debt in Software-Reliant Systems”, presented at the Future of Software Engineering Research (FoSER) workshop in November 7-8, 2010 (preprint).
  3. We also created a little board game to illustrate the concept of technical debt. It is called Hard Choices, and is available to download and play (and improve) under a Creative Commons license. I’ve played it with various audience, architects, business analysits and university students in many places around the world.
  4. We will organize a workshop on technical debt in May 2011, at ICSE, in Hawaii and we invite practitioners and researchers to come and share their findings, opinions, methods,  on technical debt. Se the call for contributions here.
  5. I made this month several presentations on technical debt while in the Netherlands. See my Talks page, or this link for a copy of the slides.

Amsterdam students playing Hard Choices

Contextualizing Agile Software Development

September 8, 2010

I made a presentation at the EuroSPI conference on the importance of the context in software development. The corresponding paper:Kruchten 2010 ContextualizingAgilityFinal contains more details than my blog post from July 22. In particular I spoke about a possible use of “the Octopus” for sorting out practices. Here’s how the beginning of a “practice sieve” could look like:

A longer academic paper was published here.

Agility and Architecture

April 10, 2010

There is a special issue of IEEE Software on agility and architecture, which I co-edited with Pekka Abrahamsson and Muhammad Ali Babar. Several papers have been made available by IEEE here, including our own editorial introduction.

Nihon-go special (for my Japanese readers)

January 24, 2010

In December 2009, I made several presentations in Japan. Here are the slides in Japanese, translated by Dr.  Taku Fujii, from OGIS-RI:

And my books have been translated in Japanese, the first by Dr. Fujii himself:

the latter by folks at IBM Japan System Engineering.

The Context of Software Development

July 22, 2009

fig-1-contextFor real estate, the motto is “Location, location, location.” For software process, it should be “context, context, context.” In my rant paper Voyage in the Agile Memeplex in ACM Queue, I stressed the absolute necessity to put our processes in context. But “what is this “context” you keep referring to, Philippe?”, many people asked, “what is this context made up from?”. It is very unfortunate that too many advocates of agile development practice are preaching good practices, but completely removed from the context in which they were proven to be successful. It turns some of their followers, several levels of transmission down to become just blind bigots, sometimes rabid bigots (again see my paper for this phenomenon and the down side of decontextualization).

I provided some elements of response in my XP 2008 Keynote speech in Limerick. The short answer is in figure 1.

Read more…

Metaphors in Software Architecture

July 21, 2009

There is one constant, throughout the whole (short) history of software architecture, and regardless of the formality of the approach: it is the systematic use of metaphors to describe architectural elements and architectures.

Metaphors give meaning to form and help us ground our conceptual systems. A metaphor is a form of language that compares seemingly unrelated subjects: a rhetorical trope that describes a first subject as being equal or very similar to a second object in some way. A metaphor implies a source domain: the domain from which we draw metaphorical expressions, and a target domain, which is the conceptual domain we try to understand or to describe. The metaphor operates a cognitive transfer from the source to the target; it says in essence: “<the target> is <the source>.” Others call them the ‘metaphrand’ and the ‘metaphier’.

Read more…