Interview on Technical debt
The nice folks at TechDebt.org have “interviewed” me over the web about technical debt. Transcript available on their web site here.
Podcast on Devnology
During my last trip through the Netherlands, I spent an hour with Freek Lemhuis and Arne Timmerman from Devnology (a dutch community software development website/blog), and they recorded this podcast, asking me about the agile elephants in the room, RUP, and other topics, such as cognitive biases and reasoning fallacies.
Podcast here: http://devnology.nl/nl/podcast/10-content/224-devnology-podcast-032-philippe-kruchten
Via iTunes: http://itunes.apple.com/podcast/devnology-podcast/id335170002?mt=2&subMediaType=Audio
Agility and architecture koan
“Self-organizing teams can decide everything by themselves. So they don’t need an architect.” writes Samudra Kanankearachchi on the Software Architecture group of LinkedIn.
This feels to me like one of these strange agile koans. If you repeat it often and long enough, it will gradually become the truth.
Self-organizing teams have very little to do with the architecture of your system. Self-organizing teams are about: task allocation, collaboration, communication, accountability, … it may have to do with time-boxing and therefore what gets accomplished in a certain time-frame. Architecture is about making decisions (choices) about the structure, composition, organization of the software system. It also feels like “architect” is necessarily not a member of the team. Not my personal experience or recommendation. Architect is a role, not necessarily a person (whose only role is to be an architect, though these exist in large organizations.)
Most systems tackled by small agile teams have a pre-defined stable architecture. So yes, they do not need to have anyone playing the role of architect. For novel complex systems, where architectural decisions need to be made, if they are made “by the team”, it means that the team plays the role of architect, and hopefully they have the knowledge and experience to do so. Like some teams have a scrummaster and a product owner, such teams should have an architecture owner, who drives the discovery of architectural issues and their resolution. Because an architecture is not going to gradually emerge out of weekly refactorings (another agile koan), unless this emergence is guided somehow.
There was a whole issue of IEEE Software magazine last year dedicated to the interplay agility-architecture. Start here: http://www.computer.org/portal/web/computingnow/archive/april2010 . Some of my own prose to be found there.
We do not need richer software process models
A group of researchers is looking to issue a Manifesto for Rich Software Process Models. Here’s my position on this topic.
“… perfection is achieved not when there is nothing left to add, but when there is nothing left to take away.” Antoine de St. Exupéry, Terre des Hommes, 1939, chap.3
Over the last 30 years we have tried very hard the rich process models, and we have not been extremely successful at it. Maybe we should try lean and mean software process models, rather than making them “richer.” At minimum, we should try to analyze why the rich approaches have not worked; where they failed. Could it be that we were trying to solve the wrong problem? or that the real problems by far overshadow the process model issue? Or maybe the whole construction paradigm we use for software development is not adapted anymore? My position is that we should try the route of very simple software process models, to ensure a wider applicability, greater versatility, and acceptance. Possibly these new process models would be based on other paradigms of software or system development than the “technical-rational” construction idea. I would be wary of richer process models. Read more…
The Daily Stand-up Meeting from Hell
Last year, while I was the “academic-in-residence” at Software Education in New Zealand, we wrote and shot this little video, to illustrate all that can go wrong during a daily stand-up meeting. I use it in class to start a discussion on the practice. Ask me if you want the original file (197Mb).
Click here to see the video on Youtube
Video on YouTube: The daily Stand Up Meeting
The Daily Stand up by Philippe Kruchten is licensed under a Creative Commons Attribution-NoDerivs 2.5 Canada License.
The Elephants in the Agile Room
An “elephant in the room” is a metaphor for the behaviour of people who deliberately ignore an impending issue. They are fully aware of some major issue that really must be tackled or decided upon, but everyone keeps busy tackling other, often small items, ignoring the big issue, pretending it does not exist, hoping maybe that it will vanish by magic or that someone else will take care of it; that one day the elephant will have left the room.
During the 10 years agile celebration meeting in Snowbird, UT, organized by Alistair Cockburn on February 12, after covering the walls with a couple of hundred issues cards, David Anderson noted that there was “an elephant in the room”, a topic that few are willing to debate in the pen, namely the Agile Alliance (its role, mission, accomplishments, etc.). After the lunch, a small group gathered and identified a few other such elephants in the room, other topics that the agile community is not really willing to tackle for a variety of reasons. We ended up with a long list of about 12 such “undiscussable” topics (or at least not discussable in the open).
Here they are, with an additional sentence to explain what the title is about, based on the best of my recollection (see photograph at bottom): Read more…
The Frog and the Octopus go to Snowbird
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!”:
Slides:
… 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
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
See more here: Contextualizing software development
And in summary: we need both to really understand software development project.
Note: we love to eat frogs and octopus. The ultimate fusion between French and Japanese food.
Technical Debt – Workshop, paper, game, presentation
News: 2nd Technical debt workshop in May in Honolulu…
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:
- Steve McConnell, Notes on Technical Debt (2007), Blog post
- Martin Fowler, Technical debt quadrant (2009), Blog post
- Useful material on this topic from folks at the Cutter Consortium (I. Gat, J. Highsmith et al.) is unfortunately more hidden. (Actually, they offer the whole special issue for free, for a short while: http://www.cutter.com/offers/technicaldebt.html.)
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.
- As part of that effort we have organized a workshop on technical debt on June 2-3, 2010 in Pittsburgh,
- 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).
- 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.
- 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.
- 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
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
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 http://www.computer.org/cn, including our own editorial introduction.
Philippe Kruchten 