Conference Chair: Till Schümmer
Program Chair: Lise Hvatum
Program Committee: Paris Avgeriou, Arno Haase, Neil Harrison, Lise Hvatum, Allan Kelly, Michael Kircher, Andy Longshaw, Klaus Marquardt, Till Schümmer, Didi Schütz, Markus Völter, Uwe Zdun
Workshop Leader: Allan Kelly
Workshop Leader: Till Schümmer
Workshop Leader: Dietmar Schütz
Workshop Leader: Klaus Marquardt
Writing Group Leader: Uwe Zdun
Organized by Klaus Marquardt and Kevlin Henney
Beyond software development, there is more to the software lifecycle than maintenance. From a developer’s perspective, the focus on development can be considered only natural.
However, it is very much an inward looking perspective. The software needs to be brought to the end user, and the end user and various customer stakeholders will care about the software beyond its initial release.
To the extent that they influence the development and architecture, the logistics of software deployment are the topic of this focus group. This includes
Process and Results
Some work is available as a would-be pattern language. This focus group shall add to the pattern collection by including a broader experience, and explore sequences to shape the pattern language.
For the focus group, we will use an abbreviated pattern format that helps to focus on sequences. The existing patterns will be brought to the workshop in that format. Participants are asked to prepare in advance, but unprepared guests are welcome as well.
Organized by Klaus Marquardt, Lise Hvatum, and Dietmar Schütz
Just like stranded whales suffocate from their own weight, projects can suffocate from their own complexity. To successfully run and finish a project, its complexity must be known and managed.
This focus group shall explore the current state of complexity metrics, the related heuristics, and collect the management practices in a pattern form.
Process and Results
The group will start out to identify where complexity is within some project, how it is introduced into the project, and how to get rid of it (where possible) or circumvent it.
Organized by Michael Weiss, Aliaksandr Birukou, and Paolo Giorgini
How do you find a pattern? Do you A. Flip through the patterns books on your shelf, B. Google, C. Not bother and stick with what you know, or do you D. Search a pattern repository. We will explore the issues in making a repository work well. Some of questions for which we hope to get answers are how do you organize and search pattern repositories, how do you integrate them with your development process, and how do you create a community of users around a repository.
More details can be found in this PDF file.
News: The focus group has created a wiki for off-site interaction: http://www.patternforge.net/wiki.
Organized by Andreas Rüping
In discussions you often hear the following pros and cons:
+ Ajax-based web applications are much more interactive than anything we’ve known before. Only Ajax makes a vast user participation possible.
+ Ajax-based web applications are much faster than traditional web applications. Fewer pages are loaded, and some of the page loading can be done in the background asynchonously.
– Ajax blurs the concept of a web page. The back button can no longer be used, bookmarkability is ruined, and web pages cannot be found by search engines.
These pros and cons read a bit like a system of conflicting forces, so why not try to resolve these forces and figure out what techniques really work, and how?
The perspective of this focus group is to:
Organized by Andy Longshaw and Kevlin Henney
There are many methodologies and collections of software development practices that are used in different organizations and by software development teams within those organizations. Some of these organizations successfully produce software-intensive systems while others simply produce high levels of stress. In some cases, successful and unsuccessful organizations use, or purport to use, the same software development methodology, so why do they not get the same results? If an approach fails, it is likely that reluctant adopters and cynical stakeholders will blame the methodology and that the methodologists and enthusiastic adopters will blame the organization and the application of the method. This observation applies as much to individuals and their practices as it does to teams and whole organizations: whether it is naming conventions, programmer testing, class hierarchy design or pairing, “that works for me” does not always translate to “that should work for you”.
It is well knows that certain software products and frameworks have a “sweet spot”: a target environment or projected mode of operation under which the product will perform optimally. When you move outside that sweet spot, not only may the operation of the product become sub-optimal but it may actually start to become detrimental to the operation of the system as a whole. By and large, methodologies and software development practices do not come with an explicit sweet spot (or in their case an expected organizational context and matching individual aptitudes) and, being concerned with people rather than software, they are not as clearly bounded as frameworks. Furthermore, for a variety of reasons, methodologies have a tendency to generalize over time.
However, our hypothesis would be that methodologies and practices also have such a sweet spot in which they operate best and – just as with a software product – straying too far outside this sweet spot can cause the practices to become counter-productive. In both success and failure stories, there is a great deal of implicit detail that contributes to the eventual outcome. By making more of this explicit, could we expect more effective adoption of practices?
This focus group looks to explore which practices work (and which ones don’t) in different types of organization and software development environments and with different kinds of people. Questions we will look to answer include:
Organized by Marina Haase
We all know the situation: We are new in an IT-Project – there is very little documentation, and very few people to help us get into the project. I’m implying that most of us don’t just arrive in a project – and “hey, presto!” by magic understand the project, are integrated in the team and start being productive.
I’m sure over the years many of you have collected best practices that you repeat when arriving in new project contexts… and I have started analysing what I do – what doesn’t work and what does… and probably will work next time too! The goal of this focus group is to collect proven best practices for getting into projects and start being productive quickly.
We will spend the first few minutes introducing our best practices. Then we will spend a few moments thinking and brainstorming about the problems that occur when starting out in projects. We will then try and associate the problems to the collected best practices or other ideas of best practices. After this we will divide into groups and brainstorm about forces and consequences of first pattern ideas. Ideally at the end of the focus group we will have generated a collection of pattern beginnings that might be documented in detail at a future Europlop.