12th European Conference on Object-Oriented Programming Brussels, Belgium, July 20 - 24, 1998
	Panels

The technical track of ECOOP'98 is host for two panel sessions from the two extremes of the spectrum. On the one hand, current software engineering practices are examined by some of the most renowned but at the same time critically inclined specialists in the field. In particular the success/failure rate of large scale software projects is put in the balance against the practices and metrics prescribed today. On the other hand, a second panel will investigate the cohabitation of programming paradigms with object orientation and should therefore appeal to the more technically minded. Due to the growing maturity of the object-oriented community we might even get to see ECOOP participants equally familiar with both topics...

Ghislain Hoffman
ECOOP'98 Panel Chair

Panel I (Wednesday, July 22)

Moderator:

James Coplien (cope@bell-labs.com)

Dr. Tim Budd, Oregon State University
Prof. Dr. Ulrich Eisenenecker, Fachhochschule Heidelberg
Dr. Ole Lehrmann Madsen, Aarhus University

Abstract

Object-Oriented programming exists in several flavours - even in practice. When the spectrum - say from Beta to CLOS - is examined, the paradigm appears in various shapes. But there is more.

Object orientation has a long history of coexistence with other programming paradigms. It is often grafted onto existing languages or systems with radically different scopes. Interaction between paradigms is either avoided or welcomed but never ignored.

In this panel a number of prominent members in the OOP-community are sounded for their insights in this phenomenon.

Moderator:

Martine Devos, Argo (Mdevos@argo.be)

Frank Buschman, Siemens (Frank.Buschmann@mchp.siemens.de)
Alistair Cockburn, Humans and Technology (Alistair.Cockburn@norges-bank.no)
Derek Coleman, King's College London (derek@dcs.kcl.ac.uk)
Martin Fowler, independent consultant (fowler@acm.org)
Ralph Hodgson, IBM Consulting Group (rhodgson@us.ibm.com)
Lizette Velasquez, Bell Labs (lizette@lucent.com)

Abstract

Projects fail because we don't properly manage the risks, because we build the wrong thing or because we are focused on technology. Object orientation enables us to better react to a changing understanding of the real problem. But do our methods and processes really support us? Many software development projects don't practice strict software engineering practices. Traceable agreed upon requirements documents and specs do not exist, analysis and design documentation is incomplete and not up-to-date, testing is done without formal plans and formal inspections are non-existent. Many of these projects fail. And yet some succeed. Some succeed heroically without formal schedules, without "full" analysis and design documentation, scenarios penciled on bits of paper. We need to understand and acknowledge success and failure of software projects and its deeper causes.

Issues

Why do software projects fail? Why do they succeed? Is success of a software project possible without strict adherence to prescribed software engineering practices and metrics? What minimum practices should be applied; what minimum set of deliverables ­ if any ­ guarantees success?

Do we really exploit the characteristics of software ­ its soft characteristics ­ or is software too much engineering and not enough art? How much method do we need?

How does a project reconcile the creative needs of individual highly skilled programmers with management needs for stability and predictability?

Can we learn from other disciplines, do we need new metaphors?

More detailed information and the positions of the members of this panel.