# Problem Graphs

A problem graph is a directed, irreflexive graph that is used to model the relationships between problems and their solutions.

This is a relatively simple example:

What this graph models is basically that the problem `Spamming`

can be prevented by using `Captchas`

. But `Captchas`

in turn introduce a UX problem since the user is annoyed with extra input fields.

A graph like this is *bipartit*, since a solution only causes problems and a problem can only be fixed by a solution.

This graph shows two other properties one should be aware of:

On the left we have the Problem `A`

which has two solutions `B`

and `C`

. The important thing here is that those two solutions are *alternatives*. While on the right we have a solution `X`

which causes two problems `Y`

and `Z`

. Here the two problems are caused simultaneously and have both to be solved.

The following graph shows a *dilemma*:

It is the simplest version of a dilemma. A dilemma is basically a cycle in the graph. But this example is actually a bad one, because a solution for a problem that causes the same problem again is not actually a real solution. So here is a better example of a dilemma.

As one can see, we have a cycle in the graph, which is a requirement for a dilemma. There is one catch though:

Even though this graph contains a cycle, it does actually not fall prone to a dilemma. There is a cycle, but since solutions are alternatives, one can pick solution `S3`

which is not part of the cycle. So this graph contains a dilemma, but when trying to calculate a working solution for problem `P1`

it would result in `S3`

.

## Purpose

When looking at these simple graphs it seems a little stupid to create a graph since you can reason about this stuff in your head. But when the graph grows bigger and the interdependencies between problems and solutions become overwhelming, it is good to have a data structure and some algorithms to tackle the bigger graphs.

## Extensions

The graphs above only display dichotomous relations, meaning that a solution either causes a problem - or - it does not. In real situations this is often not the case. Instead a solution might cause a problem with certain strength or weight. E.g. long loading times of the homepage can be addressed by several counter-measures and optimizations with different effectiveness. One also could factor in costs of problems and solutions (time, money, human resources, occupied equipment, …).