| 134 |
|
Some bugs can be tracked down to the method or even the single line of code that causes them. Once found, these are usually easily fixed. Unfortunately, some are properties of the system as a whole: no one subsystem, class or method is responsible for them. Leaking memory and other resources, overflowing the stack and freezing the user interface even while idle are common consequences. Problems may also appear even before run-time as fundamental conflicts in the way the components in a system work, making part of the development effort a damage-limitation exercise.
Bugs like these can be very expensive to find and correct (being impossible to localise), and may appear very late in development as bug-free subsystems are combined for the first time. This can lead to a lot of back-tracking. Even worse, in these conditions there may be a strong temptation to kludge around the problem.
|
Staffordshire University | I am now completing a PhD thesis on "Foundations of Software Reuse", an analysis of the principles underlying software reuse: from strategic organisational objectives behind the development, purchase and reuse of infrastructure software, to technical problems posed by evolving requirements in the presence of sharing and unintended emergent phenomena such as multiple event-loop conflicts. The design and implementation of software and the collective structure of reusable artifacts plays a pivotal role in determining reusability at organisational level, and forms the focus of my research. I have degrees from Southampton University and Oxford University, and have previously worked as a system architect.
|
Participants will learn what "bugbears" are, how they appear in systems, why their presence is so hard to foresee, and why we cannot trace localised causes for them. Participants will also see some examples of "bugbears" and how they were caused.
The purpose of the workshop is to identify ways in which they can be brought to light earlier or avoided completely within the context of modern development techniques, methods and technology.
The results of the workshop will be formulated as antipatterns to aid recognition of problems and guide avoidance strategies.
| Session: Workshop 170 minutes | Level: advanced |
|
Audience: The workshop is aimed at all software designers/developers concerned with large systems, increasing software reuse, or interested in purchasing strategic software resources from outside vendors.
| Max 24 (6 groups of 4) |
No material will be required in advance of the session itself.
Results of the workshop will be recorded in poster form, and transcribed (after the event) into antipattern form (a description of a problem, means for identifying when it is present, and a refactored solution that explains how to improve the situation) by the organiser.
These will be published via a web site, and possibly via the OOPS Newsletter. Posters may be made available during the conference.
There will be an initial introductory "lecture", since it seems likely that many participants will be unfamiliar or will not have thought deeply about these issues. This will be followed by group work
The participants will work in groups to examine a variety of issues which lead to these late-breaking emergent problems. Group work is intended to help participants pool their experiences.
| 134 |
|