Feel the Pain/alx

Feel the Pain
Contributors	Christian Köppe
Last modification	May 17, 2017
Source	Köppe (2011); Köppe (2013)
Pattern formats	OPR Alexandrian
Usability
Learning domain
Stakeholders

Also Known As: Experience of Problems (Experience of Problems), Experienced Problem (Experienced Problem)

The aim of the wise is not to secure pleasure, but to avoid pain. -Aristotle

Students often have (naturally) a limited experience in the domain of their study. This experience is mainly based on some school projects, but these school projects are of limited scope themselves due to time constraints and other environmental factors like the size of classes or the teaching model.

***

Students often apply patterns without understanding why the problem really is a problem. They are not aware of the consequences if this problem is not addressed properly.

The required functionality of a software system can be implemented in countless ways. Only a few of these ways equally respect and balance the non-functional requirements of the system too, while the others often lead to a Big Ball Of Mud (Big Ball Of Mud). Many problems related to non-functional requirements emerge long after they have been caused.

Shortened Software Lifecycle. As students’ projects are often of limited scope, these non-functional requirements — even if gathered and described in the beginning of the project — are not obviously necessary and of value to students, as the phase where these requirements become important is mostly out of the scope of the project. The need for — and advantage of — the consideration of these requirements during design becomes hence not obvious to the students.

Sparse Experience. The problems which are addressed by the different design patterns are often ones that students have never experienced by themselves. The consequences of high coupling, low cohesion, low modifiability etc. are not obvious to them, so they often just implement the required functionality without thinking about possible consequences for the non-functional requirements.

***

Therefore: Let the students experience the problems addressed by a pattern first hand before they implement the pattern. Help them to understand what consequences it has if these problems are not addressed appropriately.

This pattern is specific for teaching design patterns to students without prior (excessive) design experience. It also can be inappropriate to let pattern users experience the problems addressed by the patterns, e.g. when teaching pedagogical patterns one should not enforce the problems addressed by pedagogical patterns. We therefore do not consider this as sufficiently high-level to be marked with one asterisk.

Experiencing a problem yourself improves the awareness of this particular problem, but also the awareness of why a problem should have been understood properly before solving it. This might require the adaptation of some existing exercises in a way that also the phases of the software lifecycle are covered so that the problems can actually be experienced. In software engineering projects most often this will be the integration or maintenance phase. So possible applications of this pattern could be the task of implementing a new requirement which has huge impact on the current design, or the integration of a new component in a software system.

Astrachan et al. used this technique as well. They based it on the idea that “good design comes from experience, and experience comes from bad design” (attributed to Fred Brooks and Henry Petroski according to Astrachan).

An important aspect is that the students should not have the experience of complete failing up to the point of loss of motivation. Struggling with the problem and having difficulties to solve it are necessary part of the solution, but should not have a negative effect on the students’ self-confidence. This requires a sensible application of this pattern: the period where the students actually “feel the pain” should be long enough to make the point, but not longer.

Immediately after feeling the pain of an unsolved problem, the students should look for the Best Fitting Pattern Choice (Best Fitting Pattern Choice) and, when found, should see and have the Experience of Benefits (Experience of Benefits) which the solving of the problem gives them. Astrachan et al. describe this as the before and after model .

The application of this pattern is often not necessary in commercial contexts, where trainings in design patterns are given to somewhat experienced software developers or designers. These people often have a good understanding of the problems, as they have experienced them themselves and these problems were often the reason for following the course on design patterns.

We implemented this pattern in a workshop using Class-ResponsibilitiesCollaboration (CRC) cards as introduced by Beck and Cunningham. Prior to the introduction of the Observer (Observer) pattern the students were asked to think of classes and a mechanism which automatically represents changes different values on different display types (which is actually one of the most often found examples of a possible Observer-application). They were required to use the CRC cards for the design process. After finishing their designs, they had to replay a simple change of one value including the automatic refresh of all representations. Then they had to add another representation and to discuss what they had to change in their design and how difficult this was. This way the students recognized that even a small addition of another display can require a relative large amount of changes.

This pattern can also be found in an exercise Cinn´eide and Tynan gave their students. The students had to implement an extension for two different solutions which were given to them. One of these solutions made use of design patterns while the other solution was using an ad-hoc implementation without a good design. The students struggled with the ad-hoc solution, trying to figure out the complex control flow and where to put what code in order to implement the extension. They therefore experienced the maintenance problems generated with this bad design and were able to compare this experience with the one made while extending the well-designed solution, which used design patterns. So this exercise implemented both Experience of Problems (Experience of Problems) and Experience of Benefits (Experience of Benefits).

Eduardo Guerra also uses this pattern in his lecture on ”Understanding Design Patterns” (in combination with Discover Your Own Pattern (Discover Your Own Pattern) and Experience of Benefits (Experience of Benefits)). He starts there to work towards a complex UI-menu structure, initially without making use of the later introduced Strategy (Strategy) Pattern. During this design process many problems are detected and identified, which shows the students that the straightforward approach presented by Guerra obviously leads to design problems.

In the book Head First Design Patterns. much attention is spent on the problems the design patterns are addressing. All these problems are discussed in detail and also related to the principles possibly violated by applying a simple solution to them.

This pattern is also implemented in the assignments given by Uwe Zdun in his course on software architecture at the University of Vienna.