Where are you from?
I was born in Strassbourg, but now live in Vancouver in Canada.
Where do you do your daily work?
Most of the time I’m at the university in Vancouver, where I’m a professor.
You haven’t been a professor for that many years. What made you take the jump from commercial software development to the university
Academia is my retirement position, or my hobby, you might say. I worked at Rational for a lot of years, but left it shortly after IBM bought Rational.
Such a move is not all that unusual – Barry Boehm did the same thing. Actually, I wasn’t really sure that a position at the university was what I wanted, but I’ve known Barry for a long time, and he was the guy who encouraged me to go to academia.
Have you been to JAOO before?
No, it’s my first time. I do maybe 3 or 4 conferences a year. I’m not so keen on going as an attendee, I like to organize workshops and tutorials instead. Used to go systemically to OOPSLA, ICSE, doing one of them each year, but I haven’t been there for 2 or 3 years.
I’ve been part of the Agile Conference organizing committee for last 2-3 years. It works a little bit like JAOO, with speakers coming following their own proposals, but also by invitation. We don’t use formal papers, though – with the exception with the one track reserved for academic research talks.
As an academic, have you got any thoughts about going to a fairly commercial conference like JAOO?
I don’t see myself as opposed to commercial conferences, given that I’ve been in the commercial industry for quite some years. At Rational, we even had our own conference.
You are known for the invention of RUP 4+1, but now you are into this whole agile architecture/documentation thing. I must admit, personally I’ve never been a big fan of the RUP, but I do see it containing some mature properties lacking in many agile projects. Do you see any signs of Agile “growing up” in terms of documentation
First, I’d like to say that many people misuse RUP. It’s like I give you a recipe book – and you think that if you want to use the book, you’ll have to do every single recipes. I guess you would find that a little heavy weight too. Organizations say “RUP forces us to do X”, but RUP doesn’t force you to do anything. We wanted to collect recipes for doing things, to let people pick the ones they need.
To me it seems the Agile movement is going a little bit in all directions. Agile is a “Guru”-driven business – with all kinds of brilliant people running around shouting things like “Kanban is better than Scrum”, “Scrum is better than Kanban”, “XP and Scrum are compatible”, “No they’re not” – and so on.
So to contrast the two approaches, RUP was assembled systematically and as a coherent whole. The agile movement is all about everyone doing things their own way. It’s fun, but also confusing for people. There’s really no shared vocabulary.
Talking generally about documenting architecture and design, I think we’re beginning to realise that Design Decisions are first class citizens. Just having a static description of the architecture won’t be of much help if you’re in a situation where you need to maintain a legacy system. You need the decisions too, the rationales that was made in constructing the design in question. Actually, you can rebuild the entire architecture if you know the decisions – but not the other way around.
Design Decisions are part of the glue between requirements and the final design. The problem in capturing them is, that very often the naïve approach is “let’s build a tool to capture decisions, then ask designer to enter decisions”. But the designer has more important things to do than “feeding the beast”.
So we must find a more subtle way to capture decisions. And the way must not demand a lot from the designers – there’s no real incentive for them to capture anything: the pain of not having captured it might not be induced years later when the need to maintain or extend the system arises. And chances are, that will be the job of someone else.
If you had not become a software engineer, what would your career have looked like?
Actually, I’m not a software engineer. My education is as a mechanical engineer. But then again, I did my Ph. D. in computer science.
Retrospectally, I think I would have been become a structural engineer, working with architects. But Around the beginning of the 70’s, it looked like the money was in software… I guess time didn’t prove that wrong.
Already as a student, I was making lots of money writing Fortran programs. I was hired to do software for IBM, it ment nothing that I wasn’t educated for it, as long as I knew how to code.
I really hated that job, and I quiet after 4 months. And then, 33 years later they bought my company, making me once again an IBM employee. I was still in their employee database. “Lucky you, Philippe, we can add 4 months of seniority…”
At JAOO, Philippe will do the talk “Documenting Design and Architecture” about design decisions and rationale, how you represent architecture and capture the history.. Wednesday at 14.45.
Where are you from?
I was born in Strassbourg, but now live in Vancouver in Canada.
Where do you do your daily work?
Most of the time I’m at the university in Vancouver, where I’m a professor.
You haven’t been a professor for that many years. What made you take the jump from commercial software development to the university?
Academia is my retirement position, or my hobby, you might say. I worked at Rational for a lot of years, but left it shortly after IBM bought Rational.
Such a move is not all that unusual – Barry Boehm did the same thing. Actually, I wasn’t really sure that a position at the university was what I wanted, but I’ve known Barry for a long time, and he was the guy who encouraged me to go to academia.
Have you been to JAOO before?
No, it’s my first time. I do maybe 3 or 4 conferences a year. I’m not so keen on going as an attendee, I like to organize workshops and tutorials instead. Used to go systemically to OOPSLA, ICSE, doing one of them each year, but I haven’t been there for 2 or 3 years.
I’ve been part of the Agile Conference organizing committee for last 2-3 years. It works a little bit like JAOO, with speakers coming following their own proposals, but also by invitation. We don’t use formal papers, though – with the exception with the one track reserved for academic research talks.
As an academic, have you got any thoughts about going to a fairly commercial conference like JAOO?
I don’t see myself as opposed to commercial conferences, given that I’ve been in the commercial industry for quite some years. At Rational, we even had our own conference.
You are known for the invention of RUP 4+1, but now you are into this whole agile architecture/documentation thing. I must admit, personally I’ve never been a big fan of the RUP, but I do see it containing some mature properties lacking in many agile projects. Do you see any signs of Agile “growing up” in terms of documentation?
First, I’d like to say that many people misuse RUP. It’s like I give you a recipe book – and you think that if you want to use the book, you’ll have to do every single recipes. I guess you would find that a little heavy weight too. Organizations say “RUP forces us to do X”, but RUP doesn’t force you to do anything. We wanted to collect recipes for doing things, to let people pick the ones they need.
To me it seems the Agile movement is going a little bit in all directions. Agile is a “Guru”-driven business – with all kinds of brilliant people running around shouting things like “Kanban is better than Scrum”, “Scrum is better than Kanban”, “XP and Scrum are compatible”, “No they’re not” – and so on.
So to contrast the two approaches, RUP was assembled systematically and as a coherent whole. The agile movement is all about everyone doing things their own way. It’s fun, but also confusing for people. There’s really no shared vocabulary.
Talking generally about documenting architecture and design, I think we’re beginning to realise that Design Decisions are first class citizens. Just having a static description of the architecture won’t be of much help if you’re in a situation where you need to maintain a legacy system. You need the decisions too, the rationales that was made in constructing the design in question. Actually, you can rebuild the entire architecture if you know the decisions – but not the other way around.
Design Decisions are part of the glue between requirements and the final design. The problem in capturing them is, that very often the naïve approach is “let’s build a tool to capture decisions, then ask designer to enter decisions”. But the designer has more important things to do than “feeding the beast”.
So we must find a more subtle way to capture decisions. And the way must not demand a lot from the designers – there’s no real incentive for them to capture anything: the pain of not having captured it might not be induced years later when the need to maintain or extend the system arises. And chances are, that will be the job of someone else.
If you had not become a software engineer, what would your career have looked like?
Actually, I’m not a software engineer. My education is as a mechanical engineer. But then again, I did my Ph. D. in computer science.
Retrospectally, I think I would have been become a structural engineer, working with architects. But Around the beginning of the 70’s, it looked like the money was in software… I guess time didn’t prove that wrong.
Already as a student, I was making lots of money writing Fortran programs. I was hired to do software for IBM, it ment nothing that I wasn’t educated for it, as long as I knew how to code.
I really hated that job, and I quit after 4 months. And then, 33 years later they bought my company, making me once again an IBM employee. I was still in their employee database. “Lucky you, Philippe, we can add 4 months of seniority…”
At JAOO, Philippe will do the talk “Documenting Design and Architecture” about design decisions and rationale, how you represent architecture and capture the history.. Wednesday at 14.45.
