July 10, 2012: Apple has closed their site MobileMe where I had all my files. I have now put them here in WordPress, and reorganized this page. But some files were either lost or superseded by more recent ones. And the URLs are different…
Here is a catalog of presentations I have made in the last 2-3 years. The handout is the latest one, and therefore may not be exactly the one you have attended.
(Click on this icon for slides or handout.)
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: Helsinki, Aug 2012)
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?
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.
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.
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”.
A conceptual model of software development (see http://philippe.kruchten.com/2011/02/10/the-frog-and-the-octopus-go-to-snowbird/)
see http://philippe.kruchten.com/2009/07/22/the-context-of-software-development/ octopus part of above