Electrical and Computer Engineering
The University of British Columbia
4046 - 2332 Main Mall
Vancouver BC V6T 1Z4
Phone: +1 604 827 5654
DVP term expires December 2014
Philippe Kruchten is professor of software engineering in
the department of electrical and computer engineering of
the University of British Columbia, in Vancouver, Canada.
He holds an NSRC Chair in design engineering. He joined
UBC in 2004 after a 30+ year career in industry, where he
worked mostly with large software-intensive systems
design, in the domains of telecommunication, defense,
aerospace and transportation. Some of his experience is
embodied in the Rational Unified Process® (RUP®) whose
development he directed from 1995 till 2003, when
Rational Software was bought by IBM. RUP includes an
architectural design method, known as “RUP 4+1 views.”
Managing technical debt
So far, the phrase “technical debt” remains a rhetorical construct – more useful for describing the intrinsic quality of a software system than a crisp, well-defined scientific notion. In 2010, a small research project under the auspices of the Software Engineering Institute (SEI) began to investigate technical debt, to consolidate information from a variety of sources, and to hold workshops to begin formalizing the concept and understanding its full potential. As one of the workshop organizers, Philippe will review different facets of technical debt as well as techniques to assess, mitigate, evaluate and reduce technical debt. He will also examine cases when technical debt can be an appropriate tactical investment -- when debt is not necessarily a “bad thing”, but rather something which can be leveraged for business advantage when incurred with full knowledge of the consequences.
Games software architects play
Over the years, we've identified some of the strategies and tactics software architects use during the design of new, bold, large software-intensive systems: divide-and-conquer, brainstorming, reuse, etc. But we have also observed some strange tactics, biases, and reasoning fallacies that creep in and pervert somehow the design process. They go by simple, funny or fancy names: anchoring, red herring, elephant in the room, post hoc ergo propter hoc, non sequitur, argumentum verbosium, etc.
This talk will include a little illustrated catalogue of these games; some examples; and a discussion of how they sometimes combine into subtle but elaborate political plots.
Agility and architecture: an oxymoron?
Software architecture is taking a bad rap with many agile proponents; whether it’s labeled as “big up-front design”, “massive documentation”, or “smell of waterfall”, it is pictured as a non-agile practice, something we do not want to even consider; though everybody wants to be called an architect. However, for certain classes of systems, ignoring architectural issues too long a project may “hit the wall” and collapse due to lack of an architectural focus.
“Agile architecture” – is it a paradox, an oxymoron, a combination of two totally incompatible approaches? In this presentation, we review the real issues at stake, moving past the rhetoric and posturing, and we suggest that the two cultures can co-exist and support each other, where appropriate. In particular, we will show that we can distinguish in the backlog visible elements (features) and invisible aspects (architecture) and their dependencies, as well as defects and technical debt.