TLDR; I can view Problem Solving as Problem Identification, Problem Solution Construction, Solution Evaluation and I can map that on to Software Development to help me communicate in normal language.
I was at the gym and a couple of thoughts came together in my head.
First was the notion that if I want to go meta to what I do in software development testing, then I might view what I’m really involved in as a problem-solving process.
But we know that.
Problem solving is already covered in lots of software development books as being analogous to the process of software development.
Heuristic Compiler
And this was actually covered pretty well in a Herbert A. Simon paper on a Heuristic Compiler.
Where he looked at “how can we automate the process of programming?” and he really came the conclusion that it was pretty hard.
Because what you’re trying to do is automate the process of problem solving and that’s quite hard.
Nowadays, we might try and use machine learning to do that. And people might be working on those kinds of problems.
But it’s still a hard thing to do.
Relentless
I was also reading this book “Relentless - the Japanese way of marketing”.
And what I find interesting in there.. there’s a quote that said that:
“marketing is too important to leave to specialists because the customer requirements can slip through the gap between the specialisms”.
So that’s much the same as with software development.
Gaps Between Specialisms
Customer requirements slip through the gap between our specialisms as well.
- We’ve got software testers.
- We’ve got software programmers.
- We’ve got a requirements analyst.
And our requirements slip through the gap.
Our needs for automated execution to determine whether the feature still works… slips through the gaps. Because testers are doing that work, but they’re too busy doing exploratory testing.
Because we’ve given it to a specialist rather than the software development process handling that problem.
If I take the notion of “software development is problem solving”.
And then chunk problem solving into:
- identifying a problem,
- coming up with a solution for the problem,
- evaluating whether that solution is effective.
Then we have a pretty good analogous model for how we pursue software development as a set of specialisms.
- Problem identification == all the requirements analysis.
- Problem solution == the actual development of a product or buying in a product.
- Solution evaluation == checking to see whether it meets the users needs. Whether we’ve done the feature right. All of that activity which we might call Testing.
And so the notion of problem solving encompassing es these internal activities.
I find that useful because the problem identification, solution, and evaluation, happens at every step in our problem solution process.
And our problem identification problem:
- is this the right problem?
- Are we trying to solve the right problem?
- Are we solving it in the right order?
- Is this the right solution?
- What alternatives do we have?
- How do we know?
For the software evaluation:
- have we evaluated this in the right way?
- Is that it?
- Do we need to do more evaluation?
- Have we evaluated it for things that we haven’t thought about yet?
All of that provides me with a useful set of chunking down models.
Describe your own models
What I encourage you to do is try and create your own models for software development, and testing.
Using normal everyday language.
Because then we’re avoiding the notion of specialisms and we can start communicating to other people.
And if we communicated software testing as a solution evaluation. e.g. Have we built the right solution?
That might help people explain what we do.
We could possibly use it as a questioning process where we ask questions of the system to see…
- Does it do what we think it does?
- Does it do things that we don’t think it does?
The more that we can drop down into normal language. The more we avoid the problem with specialization.
Specialization provides us with a unique domain language that we have to understand, and might aid ambiguous communication.
Hopefully using natural language helps us think about our work in different ways.
And that’s really important if you’re going get on top of it and take responsibility for your process.
Live Stream
This was originally a live stream that I presented as an Instagram Story so I could get the idea out of my head before I forgot. And then live on YouTube as I tried to get used to YouTube live streaming. The recording was not actually the YouTube recording because I was on the wrong wireless network with a poorer upload speed, but I was recording locally via XSplit, and I released an edited recording to YouTube.
