12th European Conference on Object-Oriented Programming
Brussels, Belgium, July 20 - 24, 1998
|
|
12th European Conference on Object-Oriented Programming |
Panel II: Positions |
Moderator:
"A successful software project is one whose deliverables satisfy and possibly exceed the user's expectations, was developed in a timely and economical fashion, and is resilient to change and adaptation." Projects fail because we don't properly manage the risks, because we build the wrong thing or because we are blindsheded by technology. What an object-orientation brings to a problem is the ability to better react to a changing understanding of the real problem. A successful object-oriented project will generate solutions that are tunable, within reason, without requiring a significant amount of rework -- I am paraphrasing Booch.
Do our methods and processes support us? Are we prepared for this when we leave university?
Software engineering practices become heavier. SEI CMM adherents suggest that management processes that are defined in the model are essential before technology can be effectively used. SEI CMM level 3 and up are said to give 50 % more chance to succeed. ISO is sold as guarantee for good practice. However these formal process models are fairly abstract and describe principles, activities and deliverables. The actual process, the process in use, often differs considerably from the espoused model, although the specified deliverables will still be produced. Thus overhead of big projects is considered inevitable and a collection of complicated systems to manage that overhead is introduced. Often the result of such management is merely better organized overhead.
At the other extreme we see chaos-tolerant methods, like Scrum, requiring that a systems development process be
Constantly measured, timely control ensures that the product is the best that can be delivered with that team, given that technology, for that environment.
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, scenario's pencilled on bits of paper.
What I fear is that current methods do not allow us to build soft enough software? Present methods and design paradigms seem to inhibit adaptability. We become experts at what we can specify in advance, working with the unstated belief that there exists an optimal solution to users' needs and that effectiveness and efficiency can be objectively evaluated using the proper methods.
Once technology is adopted by an organization, it often becomes a constraining structure that in part shapes the action space of the user. When software is designed in accordance with the formal reality of organizations, the outcome is generally a system that must be subverted to restore flexibility to end users or that leads to an organization that hobbles along with a dysfunctional system. The user organization might assimilate the technology to fit its existing structures and modes of operation. Alternatively it might change its work processes to accommodate new features and functionality.
This issue is not solved through improved methods for identifying user requirements; instead they call for a more complex process of generating fundamentally new operating alternatives.
"The system requires it", has become an accepted (and often unavoidable) justification of human behavior.
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?
At Argo we worked on a project for an administration and 700 schools. Database access, document management, decision support, workflow and support for groupwork. Users with little or no knowledge of potential benefits and risks of technology. Change imminent but unpredictable (politics)
At Argo me made a resolute choice for an architecture-driven approach, focussing on creating a framework that satisfies known "hard" requirements, and able to adapt -- resilient enough to adapt -- to those requirements that are not yet known or understood. We build softer software, supported by softer methods. Soft system thinking supporting a repository based framework.
We decided at the onset of the project that we needed a flexible approach. So we built a framework for adaptive design and support configuration of applications in this environment with intensive use of creativity techniques in workshops. The main goal of the framework design was a small kernel of generic components acting dynamically upon a meta-repository. Hard coding was to be avoided as much as possible.
After three years, we are convinced that the approach is a valid one. End-user applications can be developed iterative and incrementally, even interactively. We do not code (apart from some custom scripting) and we do not generate end-user applications. Neither do we use or need throwaway prototypes. Instead, we build increasingly complete specifications of end-user applications. These specifications are available for immediate execution. In this way, we help close the gap between analysis, design and use of applications.
We use a managed, time-boxed, iterative, incremental cycle. We apply a minimal method and stimulate the use of creativity and lateral thinking to broaden our users' scope of expectations. Flexibility and adaptability are considered more important than a full set of analysis and design drawings. Models are made on a white board or with post-its on brown paper during workshops. Users do not know what to expect, they formulate requirements in terms of past experience, so we need to create an environment and provide them tools to envision and experience the "deliverables", allow them to give feedback, incorporate the feedback in short cycles.
Our culture is centered on results -- encouraging light communication and high visibility.
A highly skilled team -- self-selecting (organization cf. Coplien's Patterns for organization) -- daily Scrummeetings -- trust a core-value The project is a constant challenge for the group and the individual developers There is space to experiment and to even "to throw one away". A very special role is given to end-users. We use qualitative measures rather than quantitative. We want users to present the system to new colleagues as the thing to use, user delight expressed through users training their peers, organizing opportunity scouting workshops, writing online help and manuals. This process was initially driven by small teams of highly motivated pioneer-users working very close to developers, and has gradually started to embrace the end-user community at large.
Our approach seems to work. 15 people on the team. Interaction with other teams, working on applications for local units, operationsÉ
Is this sheer beginners luck? Do we need CMM level 3 to be successful? The project
and the team once felt threatened when the contracting company applied for ISO and
insisted on deliverables -- that is paper proof of progress -- absorbing time and
draining creativity and enthusiasm from the team.
Credentials
Martine Devos has been IS manager at Argo since 1992. She has worked as teacher, as technical consultant and project leader to the Belgian Minister of Education, the Civil Service. She is chair of the IS managers workgroup of MOVI, representing all Flemish semi-government organizations. As IS manager she initiated, and co-ordinated the development of a framework and several applications using it. Her special interests are framework development, the use of patterns in organization, the human side of IS and facilitating workshops. She presented the framework with meta-repository architecture and methods supporting its' use in demonstrations and poster-sessions at ECOOP'96, OOPSLA'96 and '97. She participated in, and organized, several workshops on System Envisioning, and the use of creativity in requirements developing.
Alistair Cockburn was the focal point for OO in the IBM Consulting Group in the early 90's, where he wrote its OO development methodology, acted as project consultant and designer. He founded "Humans and Technology" in '74 to follow interests in cognitive, cultural, and human aspects of software development. He has written several organization-wide methodologies, working from an ethnographic basis. He just completed the book, "Surviving Your OO-project".
Derek Coleman is a co-author of "Team Fusion: Object-Oriented Developement using UML", and two other books on Fusion. He is Professor and Head of Department of Computer Science at King's College, London. Prior to this Derek was a manager at HP Laboratories in Palo Alto and Bristol (England) where he lead the development of he original Fusion method. He has authored many papers on software engineering and object technology.
Martin Fowler has spent a decade applying object technology to business information systems. He is an independent consultant who does project Mentoring and training workshops for such clients as Chrysler, Citibank, UK National Health Service, and Netscape. He likes processes that are Low on ceremony, and high on productivity and fun. He is the author of "Analysis Patterns" and "UML Distilled".
Frank Bushmann is a software engineer at Siemens, where he focuses on object-oriented technology, software reuse and patterns. Frank is co-author of "Pattern-Oriented Software Architecture: A system of patterns". Frank has been involved in several concrete industrial software development projects. At Siemens Corporate Technology, he is responsible for the research activities in patterns.
Ralph Hodgson is executive consultant at the IBM Consulting Group and has over 25 years of experience in system development. His research interests are in how enterprise architecture and enabling system concepts can be designed and implemented with new and existing technologies so as to provide effective systems to meet the challenges of adaptive enterprises. These interests encompass system development methods and process, system architecture, collaborative environments, organizational culture and change. Recent focus has been on the nature and role of "system envisioning" in requirement elicitation.
Lizette Velazques, Bell Labs, is a methodologist and domain analyst at Bell
Laboratories. At Bell Labs, she is also a member of the Object Review Consultancy
Associates group dedicated to review designs, architectures, and project strategies,
for projects using OO and to consult on tools and techniques for effective application
of OO.
Lizette has focused most of her work on the study of issues related to the transfer of
methodologies and technologies to software development organizations and their
impact on organizational behavior. Her current research interest includes Pattern
Languages, Domain Engineering and Organizational Behavior. LizetteÕs
extracurricular interests include the study of Spiritualism and triple-loop learning.
Abstracts
Position 1 -- Lizette Velazquez, Bell Laborateries: "Organizational Behavior and Software
Development Processes"
Organizations that want to improve their performance, need to learn from experience and understand the context in which they execute. Most organizational improvement programs are based on process specifications. A process can be an effective learning tool when the behavior of the organization using it is also considered as part of the systemic whole.
Porting a software development process from an organization in which it works well, for use by other organizations, is a difficult problem. I believe that successful adoption and evolution of processes requires the understanding of the organizational context in which the process is aimed to be successful. Current process descriptions rarely capture components of organizational behavior.
I have been working in a methodology/technology transfer project which has as its charter the definition and execution of a strategy to leverage a Domain Engineering process (Family, Abstraction, Specification and Translation: FAST) to achieve success in software development productivity.
The project's efforts are directed towards three main deliverables: facilitating commonality analysis in product and platform development, implementing software application environments where applicable, and technology transfer of FAST to product and platform teams, enabling them to execute the process themselves in the long run. FAST know-how is to be transferred to local domain experts and process engineers while executing FAST itself. The Domain Engineering Project also enables and facilitates commonality analysis across business group boundaries throughout the company.
I have seen success and failure not only in approaching organizations to execute the process but also success and failure in organizations that have attempted the execution of the processÉ Certainly I asked myself: Why? I wanted to know if process failures could result from conflicts between organizational behavior (and the values that drive that behavior), and the process.
My interest in understanding why some organizations were not successful in executing the process drove me to study four of the approached organizations (two of them successfully executed FAST) and the process from the organizational behavior standpoint. In this study organizational behavior was defined as the collective elements and patterns of behavior of people working in an organization. I looked at organizational behavior within organizations and across organizations in relation to FAST. In the analysis, the following questions were addressed: What is the expected impact of FAST on organizational behavior? What is the expected organizational behavior to make successful use of the intended process?What changes to behavior an organization needs to make to support the process? The study of the FAST process gave valuable information. For instance, it revealed that FAST, to be successful, expects and supports flexible and innovative organizations. It requires organizations that want to, can adapt to and can incorporate changes in their market or technological environments. The domain engineering techniques FAST enforces (commonality analysis and application engineering environments) entitle analysis and extrapolation. FAST strives for a strong long-term vision of the product definition and its corresponding development.
The two less successful organizations are very focused in their software development: an instance of a product, this release of this product, this feature in this release of this product for this customer. Further analysis showed that immediate impact on the product (e.g. lines of code) is highly valued and that it is an important reward consideration. In the context of these organizations there is a strong emphasis on short time frames, with less focus on the long term and on the "big picture". In an organization that values design more than analysis, FAST called for an investment in analysis and extrapolation. The behavior of the organizations and the value system that drives it, is an impediment to the time spent on and value derived from the actual execution of FAST commonality analysis (which is considered to be a long term investment) and hampers, and actually prevents, some of the fundamental behavior expected for the successful execution of FAST.
A grown sensibility towards organizational behavior has been developed as a result of this study. The understanding of the process and the patterns of behavior that are expected for its successful execution is giving us better alignment criteria while assessing how well the process fits a given organization. Organizations are now approached with a vivid desire to understand their organizational behavior. This, along with an understanding of the behavior required for the successful execution of the process, allow us to approach organizations and work with them more in tune to their reality.
This and other experiences indicate that when we are defining a process we need to
understand and consider the organizational behavior that has the most benefit for
executing a process. To socialize a process we need to understand the organizational
behavior of the client organization and the changes on that behavior that are required
for the successful execution of a process. I expect that the link from values, to
organizational behavior, and to development processes will give us new tools to
support us in the work we do and the environment we need to effectively define and
execute software development processes.
Position 2 -- Alistair Cockburn
P1. The software development process, as actually performed, is so complex that we cannot write it down accurately, and if we could, no one could read that description and learn to perform it.
P2. People have developed stable, workable and very different ways of working. The field is splitting into stable schools of thought. We can neither eliminate nor merge them.
P3. This means that the challenge of software development is to provide a large freedom of movement to individuals, and to set into place certain "pinch-points", where control happens. Between pinch points there is very little control. One difference that shows up immediately is that from P2, I see that each person and school will interpret "large freedom" and "little control" differently, and also select a different number of pinch points with differing amounts of control. Many people will say that their selection is minimal. Others are not interested in minimal.
P4. This matter of the amount of Prescription in the daily process, and the setting of the Pinch Points, actually affects the outcome of the project to a very large degree - more than the choice of technology does. I get to say this partly because it is true :-) and partly because I am currently managing a significant non-OO (COBOL / CICS / mainframe) project, and see the same issues and discussions here as in OO projects. I have a position about Deliverables in the development process:
P4. Deliverables in the development process inform by acting as reminders of things the reader already knows. This includes the project plan, the requirements, the design document, and the user manual. (The reader for the code is a computer, and we know how little the computer knows!) With this position, I can afford to relax considerably about the accuracy, precision and currency of deliverables. As long as they act as adequate reminders, they are adequate. It pulls along as a corollary,
P5. Low-resolution deliverables require greater person to person communication. As the communication distance between collaborators and communication difficulty between them increases, more work is needed in the deliverables, with people consequently getting less other work done.
P6. Direct and interactive person-to-person communication is the highest quality and highest bandwidth form of communication, and should be set as the preferred mode. This means that written deliverables should be viewed as crutches to be used as backup, not as the foundation for communication and thinking. Finally, but not least,
P7. Every social issue that affects morale, communication and concentration affects the outcome of the project in significant ways. These include the cultural match of the specified controls to the people in the project, the informal communication channels, the rituals of the organization. Fix these up well, and the communication will thrive (see P6).
Will be available later -- accepted
Over the last ten years I have seen many projects try to develop OO business information systems. Most of these were not well managed, a couple were. Many people have observed such problems. Many propose a solution which is founded on a more formal development process, with defined steps, defined deliverables, defined roles, and an auditable paper trail.
I've not noticed that projects using such techniques are wildly more successful.
They fail for several reasons.
Of course this begs some important questions. How much documentation is too much, how much is not enough? What are the really important things that matter? I'm looking for the answers to these questions. But I'm looking the point of view of the minimum - what is the least amount of process we need to be able to succeed? Here are some things I've learned so far.
Project success depends on satisfied customers, and nothing worries customers more than when they cannot see progress effectively. Therefore create project milestones so that they are meaningful to the customer and cannot be fudged.
You need to produce meaningful milestones for the customer, therefore base project milestones on delivering a subset of the functionality of the desired system. Such a subset should be fully working and integrated. By making it fully working and integrated you avoid putting off high risk activities to the end when they might surprise you.
A working system can make a good demo, but may fail to be a complete delivery. Bugs may lurk, and they are hard to find at the end of the project. Therefore test relentlessly. People may complain that testing is not enough to guarantee quality. This is true, but it's the best tool we have.
Developers cannot create software infinitely quickly. Priorities have to be set, and these priorities cannot be set by developers or customer alone. Therefore use a process that forces customers to make decisions on priority that are informed by the expertise of the developers.
Attention to design is useful, but as we develop software we better understand how to design a solution. Our customers can think ahead about their requirements, but as we develop software they better understand what they really need. Customers cannot be expected to know what they are asked to sign off, and developers usually don't understand either. Therefore develop plans and designs so that they encourage change during the development process. Expect mistakes to be made by both parties. Look for tools and techniques that aid redesign.
The best way to improve productivity is to have well motivated developers. To be well
motivated, developers need to enjoy themselves. Therefore use a process that pays
attention to the developers enjoying the work they do. Since most developers
enjoy delivering good software and satisfying customers, this principle is consistent
with those above. I propose to set up a web page where these position papers can be
accessed for pre-conference questions and discussion.
Position 5 -- Ralph Hodgson: "Methodology is a Social Construction"
Practising a methodology is a social construction driven by many forces. Methodology is "situated" in that it involves agreement on deliverables and work-products. These agreements will be shaped by value chains within the organizational design, appropriate to the desired architecture and consistent with reuse policies. Methodology requires "complementarity" in methods because no one approach is right for every type of design problem. Commitment to a methodology is consensus building, communication and negotiation. Such commitment often necessitates cultural change.
A work-product based approach is more favorable to success than a process-centric methodology. Work-products help a value-chain focus in that they bring attention to who has to produce what for different consumers. In addition, they encourage an architecture-centric design of the "work" that has to be done, thereby allowing more of a blending of methods according to the needs of different areas of the architecture. Development can be thought of as occurring in a series of "episodes". These episodes are often the "moments of truth" that result in a shared understanding between the different communities involved: sponsers, developers and users. Different kinds of artifacts (and interventions) are needed to make these "episodes" effective.
Envisioning a system is a creative process that establishes the possibility of viable system concepts and technologies by, first understanding problem situations and desired futures and then nominating solution architectures and designs. Models are central to development. In the envisioning and requirements gathering (and generation) phases, often, the purpose of models is to provide contexts for posing and answering questions. Our methods have to produce models that can be appreciated by different kinds of audiences. Metaphors are a powerful technique for framing such models. In the implementation phases, models serve additional purposes. Models may only be guidance for developers, or the basis for code generation or the heart of the solution if the paradigm of the system is a reflective architecture or an enactable model. Depending on the development paradigm, different methods will be required.
Position 6 -- Frank Buschmann, Siemens AG
Even in the presence of defined standard processes and technically skilled project teams still many software projects simply fail: They don't succeed in the estimated time and under the estimated costs, the system doesn't provide its required functionality, etc.
Yet other projects that do not follow defined processes do not use a specific design notation etc, succeed, and deliver the right product at the right time.
Obviously there are other factors that make projects successful or fail than the sheer presence respectively absence of standardized processes, methods and technology.
Soft and human factors seem to be the key to this issue. Processes, methods and technology are just tools that software engineering provides to teams, but a 'fool with a tool is still a fool'. If a development organization or team does not understand the manifold cultural, political, and human-individual issues, it will likely be doomed to fail in its projects.
For example, if a project team is geographically distributed, lets say in Brussels and Banga Lore, India, you are running into cultural issues, just because of the fact that clocks tick differently in India and Europe. This problem even scales up if you believe, as many traditional software process people do, that one site is just a code factory, with the architecture and design specified at the other site, and full-fledged deliverables as the way to communicate. The lack of and (cultural) understanding, and this master-servant style of communication is the factor here that at least endangers the project's success.
Or, if a project leader or team postpone decisions just because they don't want to commit to a certain direction or strategy, or if they change such decisions frequently, a project may also run into trouble.
Yet another factor for success or failure is that good designs don't just fall out of applying a general analysis and design method. Many design problems need a solution that is beyond what you can 'derive' or 'construct'. Human intelligence is needed to capture the appropriate solution, to provide architecture and designs that are complete, provide effective solutions to the given design challenges, yet being simple and elegant. Good designs expose a certain property that Dick Gabriel once called habitability: Developers feel habitable in good designs, even outsiders to the project can understand the architectural vision and concrete design that underlies the system. Interestingly, such systems are more crafted rather than constructed, they grow in a process of piecemeal growth rather than large lump design. They are products of much iteration in which each part contributes to a coherent whole. Such designs 'speak' a language that is commonly understood by system developers.
If these and others are the success factors for software projects the question arises whether or not we need all the available tools of today? Is software development an art, dependent on some genius people that can understand and handle chaos well?
Certainly not. Work in the patterns area, for example, revealed many many secrets of successful software development, covering all phases and activities. Patterns celebrate human intelligence over machine and formal construction. They capture experience that people gained over many years, experience in how to solve specific problems effectively and elegantly.
Coplien', Cockburn's and other's patterns on organization and process provide, for example, useful insights into project organization and management. If for example, the team being geographically separated in Brussels and India would follow Copes patterns, such as Architect Controls Product and Architect Always implements, the problems due to the separation of specification and coding responsibilities would never show up. Rather there would be a team of architects in control of the whole product construction, with members from all participating sites. This team would define and communicate the architectural vision and general design goals for the system with each member being also responsible for guiding the work at his/her site. A completely different approach compared to traditional models.
Same in the analysis field. There is a growing community of pattern writers, with Martin Fowler as their most visible member, that capture the wisdom of how specific domains are organized: what are the domain entities, their responsibilities, relationships, and most important, how is work organized in the domain? These people also stress, and document, the fact that certain aspects of a particular domain are stable across each concrete 'instantiation', yet others vary significantly. They allow you to define your specific domain model correctly, in terms of the domain and in terms customers can understand.
The story continues with patterns for architecture, design and programming, many of which are already part of developers' vocabulary. Countless names of well-known pattern writers are to be mentioned here.
These patterns help with 'crafting' designs in which architects, designers and programmers feel habitable. All these patterns in their entirety provide the fragments of successful software engineering. Yet we have to go a long way to understand how to select the most appropriate subset of all these patterns for a specific project and how all these patterns are tied together. If we succeed, I believe, that we are a great step forward towards having more successful software development projects than today.
And than the circle closes. All these patterns do not replace the processes, methods and techniques of today. Instead they complement these. Processes, methods, and programming paradigms provide the structural framework for organizing and doing work. The patterns show us how to do the work in the presence of a particular project and application-specific challenge and problem.
90 minutes total
5 minutes/ panelist -- 40 minutes
3 minutes round for reactions and additional questions -- 20 minutes
questions from audience -- 30 minutes