You are raising an important point. When you do not have a hypothesis, the first thing you want to do is get one :). It's like in research: the greatest problem you can have is not having a problem.
Now, how do you get a hypothesis?
You can start from some generic visualizations. The goal here is not to gain understanding, but to poke at finding interesting initial questions.
But, you actually always know something. You likely know the domain. Or you know the last tickets that are in the work. Even listening in the casual conversations is a good starting point.
When we train people, we literally start from the very issue they work on. Within 15 minutes, we typically find an interesting hypothesis to check for. For example, a dialog could go like this:
A: What do you work on?
B: A UI refreshing bug.
A: What do you think happens?
B: I do not know.
A: Why are you looking at this specific screen? (this is a key question. people often do not know why this screen and not another. If you have a 250000LOC system, you likely have some 5000 other screens you could potentially look at. Not knowing why this one is potentially interesting is not a good thing)
B: Because I think maybe it's related to how we subscribe to events.
A: How do you expect the event subscription to be like?
B: It should always happen in a method called xyz that is provided by the framework.
A: In all classes?
B: A, no. Just in components.
A: Ok, so you want to know the event handling that are not defined in xyz in subclasses of the component superclass.
B: A, right.
It's actually remarkably straightforward. Just try it.
You are raising an important point. When you do not have a hypothesis, the first thing you want to do is get one :). It's like in research: the greatest problem you can have is not having a problem.
Now, how do you get a hypothesis?
You can start from some generic visualizations. The goal here is not to gain understanding, but to poke at finding interesting initial questions.
But, you actually always know something. You likely know the domain. Or you know the last tickets that are in the work. Even listening in the casual conversations is a good starting point.
When we train people, we literally start from the very issue they work on. Within 15 minutes, we typically find an interesting hypothesis to check for. For example, a dialog could go like this:
A: What do you work on?
B: A UI refreshing bug.
A: What do you think happens?
B: I do not know.
A: Why are you looking at this specific screen? (this is a key question. people often do not know why this screen and not another. If you have a 250000LOC system, you likely have some 5000 other screens you could potentially look at. Not knowing why this one is potentially interesting is not a good thing)
B: Because I think maybe it's related to how we subscribe to events.
A: How do you expect the event subscription to be like?
B: It should always happen in a method called xyz that is provided by the framework.
A: In all classes?
B: A, no. Just in components.
A: Ok, so you want to know the event handling that are not defined in xyz in subclasses of the component superclass.
B: A, right.
It's actually remarkably straightforward. Just try it.