Skip to content


Here is a catalog of public presentations I have made in the last 10 years. The handout is the latest one, and therefore may not be exactly the one you have attended.

(Click on this iconslides for slides or handout.)

Architectural Technical Debt     (Talk at Google, March 2021)

Technical Debt: Myths & Realities  (XP2020 Keynote)

The XP 2020 conference was held online in June 8 to 12, 2020.

30 years of software architecture  (SEI webcast)

Presentation I made online when I receive the SEI’s Linda Northrop award. Video recording is here. Be aware of a gap around minute 34.

ICSA keynote 2018 (Seattle)

Advice for doctoral students.

Strategic Management of Technical Debt (ICSA, Göteborg, April 4 2017)

Technical debt, software development process

3 Tures:  Agile Vancouver October 24

System architecture, organization structure, deployment infrastructure.

See also

Reducing friction in software development . (Software Guru conference, Mexico, June 26, 2014)

Friction: both technical debt and social debt are the elements that slow down software development.

See also

What colours is your backlog? 2010 (updated for YOW! in December 2013). Video

Managing together all the features, architectural work, defect corrections and technical debt, with some tangents about  value versus cost, earned-value, velocity, … A simple strategy based on four colours to help putting it all in the same frame of reasoning.

What the heck is that thing they call ‘agile’? . (Presentation March 20 2013 at UBC)

Since around 1999 a wave of new and innovative approaches to software development have swept our world, collectively known as “agile”. They come in various favours: XP, Lean, Kanban. Agile processes are not a technology, not a science, not a product. They constitute a ‘space’ somewhat hard to define, to clearly circumscribe. They have actually more of the characteristics of a culture, or a meme complex. As a successful memeplex, they seem to reproduce and spread quite well, as witnessed by the numerous books, articles, blogs, groups, conferences that have sprouted around the world in the past 12 years. This was achieved unfortunately at the cost of much of their inherent value because of the rapid decontextualization that accompanied this spread.
Can we define objectively what is “agile”, beyond some vague and hand-wavy reference to the “agile manifesto”? Can we characterize it, measure it, compare it? When is an organization agile? more agile than another one. In this talk I’ll do a tour of the agile landscape and offer some views on what it means to be agile.

Complexity made simple . (Updated March 12, 2013, webinar with Lockheed-Martin and IEEE CS)

What make a system complex? Can we measure or estimate complexity? What makes a system simple? What does do the software systems designers have in their toolkits to address complexity?

What do the software designer have in their quiver to tackle the complexity monster. How do patterns, frameworks, tactics, mechanisms help?

Technical Debt . (updated: Zürich, Jan 2014)

The technical debt landscape… with some stress on technical debt at the architectural or structural level.Tools and techniques to help understand evaluate and reason about technical debt.Putting technical debt in a wider context of software evolution.

Why is software so bad? (is it?) . (updated: Xi’an Aug 2012)

With software so pervasive in most aspect of our lives, we all have endless stories to tell about its inadequacies, about bugs, failures or and even complete disasters. We’ve heard of the “software crisis” ever since the late 1970’s and we seem to have never gotten out of it. The “Chaos reports” spoke year after year of software project failures in the range of 30% to 50%… In this presentation, we will look at the real state of affairs: is software really that bad? We will sort out the facts from the myths. And when it is bad or inadequate, with the help of a few software luminaries that I interviewed, we’ll investigate what are the root causes and what are our prospects for the future: will we improve the situation? How? When? Is there light at the end of the tunnel?

Agility and Architecture… an oxymoron? .

How do we harmoniously marry these two concepts which seem to be at odds with each other. Do no BUFD and YAGNI mean the end of architecture? Can an architecture spontaneously emerge from weekly refactoring? A plea for the role of “architecture owner” in any project.

Games software folks play .

A collection of cognitive biases, reasoning fallacies and political games I’ve seen at work in 35 years of practice.

Developing a large, software-intensive system is made of hundred or even thousands of decisions, from tiny ones to large, wide-ranging ones. Contrary to what we believe, we (humans beings) are not fully rational agents. Our decision-making process is marred by cognitive biases and reasoning fallacies. Plus some of us play nasty political games, exploiting these biases. Our first line of defense is awareness, and a better understanding of how to think “critically”.

The frog and the octopus.

A conceptual model of software development (see

Contextualizing agile software development .

see  octopus part of above

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: