Tag Archives: software-development

From Templates to Heuristics: Enhancing Thought Work

Posted on by
2

Update 2025-10-14: This post has been updated to reflect thought work rather than knowledge work – which was pointed out by Fiona Charles as a much better description of the cognitive work performed in software development and testing. I fully agree with the distinction between knowledge work and thought work where knowledge work rather describes what LLMs do:
“..it works only from stored knowledge, matches patterns, makes some clever (we hope) predictions and does not think.” – LinkedIn post by Fiona Charles

Anime-style illustration of five software professionals sitting around a conference table, all facing a large screen displaying a colorful risk matrix grid. Each person is working on a laptop and focused on the discussion, suggesting a team analyzing project risks or testing priorities.
Risk matrix template

I once worked with a team that used a risk-scoring template.
Each risk got a number for probability and another for severity, and they multiplied them to get a total. It was meant to help decide what to test first. But as I listened to the team debate whether something was a three or a five, I realised the discussion wasn’t really about risk at all. No one talked about what those risks meant, how they might unfold, what could be done to reduce them, or what we still needed to learn.

Maybe that happened because the template did not even include “impact” as a separate topic. But I suspect the deeper issue was competence. A team comfortable discussing risk would have gone there instinctively. Here, the numbers took over and the thinking stopped.

That moment has stayed with me because it reminds me of something I’ve experienced many times. something subtle about thought work:
The way a tool is meant to guide thinking can instead replace it.

When the Form Becomes the Focus

Templates, checklists, and frameworks promise structure and consistency. In software development and testing, they’re everywhere. Test plan templates are one of those I encounter every now and then. They usually have sections for Objectives, Scope, Risks, Environment, and Schedule. It looks thorough and reassuring. It appears like you can fill one out without thinking too hard, and that’s the danger.

When a template becomes the focus, attention shifts from outcomes to outputs.
The document starts to stand in for the thought that created it. We stop asking, “What problem are we trying to solve?” and start focusing on, “Have I filled in all the sections?”

In that shift, responsibility quietly moves from the person to the process. The template gives a comforting illusion that the work has been done, even if the real thinking never happened. For people with less experience, it creates false confidence: “anyone” can fill in the blanks, so the work starts to look mechanical rather than cognitive.

A test plan template, for example, gives the impression that testing can be planned like construction: linear, predictable, and tidy. But testing is exploratory by nature. It’s a way of learning about a product, not just confirming what we already know. A static plan can’t capture that. It diminishes learning to a document.

In my experience, test plans and test planning often look different depending on the maturity of the team. In a mature team, the outcome of a planning session might be mind maps, whiteboard sketches, or lightweight notes. They are living things, short, imperfect, and full of questions. The content still matters, but the conversation around it matters more.

When Templates Actually Help

Of course, not every task in software development demands deep reflection.
Some kinds of documentation are about communication or traceability rather than discovery: release notes, version information, configuration details. In those cases, templates can be genuinely helpful. They save time, bring consistency, and reduce the chance of missing something important.

There’s nothing wrong with that. Not all work is thought work, and not all documentation should invite debate.
The key is recognising which kind of work we’re doing. If the task is largely mechanical, a template can be a useful shortcut. If the task depends on judgment, understanding, and interpretation, then a template can easily get in the way.

The problem isn’t that we use templates; it’s that we often use them everywhere, without stopping to ask whether the work in front of us is about recording information or making sense of it.

The Catch-22 of Structure

The irony is that templates usually appear with good intentions. I know this because I have created lots of checklists myself, and at first glance they might even look like templates. They promise consistency, a shared language, a way to make the invisible parts of thought work visible. And they can help. When a team is new to a problem, a bit of structure can keep things from drifting. But what starts as a way to get moving can easily turn into something that boxes people in.

To use a flexible template well, you already need the maturity that makes rigid templates unnecessary. Without that maturity, the structure that should support learning ends up replacing it. Too much structure, and people stop thinking; too little, and they struggle.

There is another layer to it as well. When a process takes over, it gives people somewhere to hide. If something goes wrong, we can point to the document and say, “But we followed the plan.” That is the quiet harm of too much structure: it makes accountability procedural instead of personal.

What breaks that loop, in my experience, is not another process but leadership, coaching, mentoring, and showing a different way of working. When people feel what it is like to work that way, to discuss, to question, to reason rather than just fill in forms, they discover that outcomes can be achieved without a template. That experience changes something deep.

I once coached a team where we decided to stop using the formal test plan template. We did not replace it with anything fancy. We just started each conversation with one question: “What do we need to learn about this product?” We used heuristics to guide our thinking. It was messy at first, but soon people began to ask sharper questions and share more ideas. The documentation did not disappear — it just looked different, smaller, and better.

From Templates to Heuristics

In thought work, I have found that heuristics serve us better than templates.
They might look similar, a list of things to consider, but the mindset is different.

A checklist says, “Do not forget these things.”
A heuristic says, “Think about these things, if they matter in this context.”

Heuristics make that kind of thinking visible.
When I test, I sometimes use heuristics like “How might this fail?” or “What happens if/when…?” They are not rules; they are reminders. Each one starts a conversation with the product rather than trying to control it.

Over the years I have collected and written about several testing heuristics and mnemonics such as SFDIPOT, RCRCRC, and FEW HICCUPS. Each serves as a prompt to think, not a promise of coverage. For readers who want to explore them more deeply, I have shared examples and links in a separate post.

What makes heuristics powerful is also what makes them fragile. They help us navigate uncertainty, but they can easily harden into rules. Checklists assume the situation is stable; heuristics assume it is not. Checklists aim for control; heuristics invite judgment.

I find heuristics fragile for another reason too. The moment I write them down, they risk becoming the very checklists they were meant to replace. Heuristics are rules of thumb meant to guide problem solving, but they are not guaranteed to be optimal or perfect. In my experience, your background, exposure to similar situations, and worldview all influence how you apply them. That makes heuristics both contextual and fallible.

The trick is to share them as conversation starters, not commandments. When I share a heuristic with someone, I try to say, “This is something that helps me think; see if and how it helps you.” That small disclaimer keeps the door open for learning.

That is also why I have grown wary of “best practices.” To me, they are just templates at scale: frozen examples of what worked once, somewhere. Good practices live in context. They grow out of the people, the product, and the problems at hand. They shift as those things shift.

Culture, Competence, and Confidence

The difference between a template that helps and one that harms often comes down to culture. In a reflective culture, a template is often a prompt for conversation. In a compliance culture, it is more like a box to tick.

I have seen both. In mature teams, templates are used lightly, edited, reworded, sometimes ignored when they do not fit. In less mature teams, templates are treated almost as sacred text. The organisation starts to value uniformity over understanding.

The paradox is that, in my experience, competence and culture grow through practice/doing, not through documents. That is why demonstration and coaching matter so much. You cannot change this with policy; you nurture it by showing what good thinking looks like.

Over time, that creates its own kind of structure, a shared sense of what good work feels like. When a team reaches that point, even if they reintroduce some form of documentation, it is no longer a threat. It becomes expressive rather than prescriptive; it records thinking instead of dictating it.

Competence Before Templates

Competence is what allows people to see context, to tell when a template applies, when it does not, and how it might need to change. Without competence, every good practice turns into a rule, every heuristic into a checklist, every conversation into a template.

So maybe the real principle is simple:
Structure seems to work best when it grows out of understanding and experience, not the other way around.

When we reach for structure before understanding, we trade thinking for form. But when we build understanding first, structure becomes a natural by-product, a way to capture and share what we have learned, not a way to avoid learning in the first place.

Maybe that is what maturity really means: not the absence of structure, but the ability to use it lightly.

The longer I work in this field, the more I’ve come to see that thinking is the real craft. The tools change, the processes come and go, but the ability to pause, to ask why, to connect dots — that’s what lasts.

I’ve realised I don’t reach for templates because they don’t fit how I think.
They make me feel limited, because thought-work isn’t linear.
Thinking, for me, has never been about ticking boxes. It’s about staying close to what’s real — even when it’s messy, uncertain, or hard to explain.

So now I’m curious:
When do templates and checklists help you think better, and when do they get in the way?

Learning Faster: Deadlifts, Software Testing and Feedback Loops

Posted on by
Reply

Reflections emerged from learning to deadlift

Many years ago, I decided I wanted to get really good at deadlifting. I can’t quite remember why, but at some point I thought: women who lift heavy are pretty badass. And I wanted to be badass too.

At first, I thought the deadlift would be simple. You just pick up a barbell from the floor, right? But like many things that look simple on the outside, the deeper I went, the more complex it became. Hip hinge, grip, bracing, bar path, leverages — all of it mattered. And because I tend to get nerdy when I learn something, I didn’t just practice in the gym. I was simultaneously watching endless of tutorials, reading articles and forum threads, and even rehearsing the hip hinge and the feeling of a proper lift without a barbell. Yes you would find me pretending to deadlift everywhere – at work, at home, in the grocery shop.

The more I dug in, the more I realized how much my progress depended on the feedback I was getting. Sometimes it came instantly, sometimes much later — but the faster and more diverse the feedback, the quicker I learned. I was starting to see some parallels connected to my profession – it reminded me of the feedback loops in software development and testing.

Reflection 1: Not All Feedback Is Useful

One of the first “feedback tools” I tried in the gym was the mirror. It gave me an instant reflection of my movement, which sounded useful in theory. In practice, though, it wasn’t reliable at all. To check myself, I had to turn my head or shift my focus — and that immediately changed my form. The feedback was there, but the very act of observing interfered with the movement.

Software has its own “mirrors”. Sometimes we interact with a system and it looks fine — the page loads, the button clicks, the response comes back — but that doesn’t mean it’s really working the way we expect.

Feedback through mirror

The feedback can be shallow, or even misleading. Other times we add log statements or quick checks that give us a sense of what’s happening, but only from a narrow angle. Just like the mirror in the gym, these signals can create an illusion of confidence while hiding what’s really going on. The real value comes when we go deeper and investigate beyond what’s immediately visible.

Reflection 2: Fast Feedback Accelerates Learning — Especially with Multiple Inputs

Feedback from recording

Recording myself in training sessions became a turning point, even if it felt really awkward at first. With video, I could almost immediately see what had happened and adjust in the very next set. That kind of instant loop accelerated my learning curve enormously.

But the video wasn’t the only input. Sometimes I could feel something was off — maybe my balance shifted, or the bar drifted away from me. That sensation alone didn’t always tell me why it happened, but the video often did. And the best feedback of all? A coach standing right beside me, shouting cues in the middle of the lift — “brace more!” or “push the floor away!” That was immediate, specific, and actionable

Testing is similar. We learn fastest when feedback is both fast and comes from multiple angles:

  • The system itself giving you signals (logs, responses, performance “feel”).
  • Tools that capture and replay what happened (recordings, traces, automated checks).
  • A colleague or peer review pointing out what you might have missed.
  • Pairing with a colleague to give a richer perspective of ideas and feedback on your own thoughts.
  • …

One perspective rarely tells the full story. It’s the mix of inputs that accelerates learning.

Reflection 3: Interpretation Unlocks the Value of Fast Feedback

Here’s an interesting note: when I first started lifting, I wouldn’t have known exactly what to look for in a video. A rounded back or hips rising too fast didn’t mean anything to me until I had learned what good looked like. Fast feedback was only useful once I had the knowledge to interpret it.

It was similar to when my testing team was asked to explore the product for security risks. They were skilled testers, but security testing was not our area of deep expertise. We could follow guidelines, try common attack patterns, and note down the responses we got — but we didn’t know whether what we were seeing was truly a vulnerability or just expected system behavior. Even when we followed recommendations from checklists, we were left wondering: Is this a real threat, or just noise?

What we really needed was someone who could interpret the signals with expertise — a security specialist who could look at the same output and say, “Yes, this is dangerous,” or “No, this is fine.” Without that, the fast feedback we were generating didn’t translate into learning. This reminded me of the feedback I got from the coach, an expert on deadlifting. So once I had learned what to look for I could make sense of my videos.

Speed matters enormously — but it only accelerates learning if you can make sense of what’s coming back.

Reflection 4: We Can Shape the Loops

As a lifter, I learned to adjust my loops. Filming myself gave me near-instant replays. Writing a training journal and reviewing previous recordings helped me see trends across months. Without those adjustments, my progress would probably have been slower.

Sometimes, I even shaped the lift itself to get more feedback. Slowing down the movement — adding pauses at the knees, or deliberately descending very slowly — gave me more time to feel what was happening and notice where my position was breaking down. It wasn’t about moving more weight, but about creating a training scenario where I could learn more from each rep.

In software, we also have the power to shape our feedback loops. We can choose what to observe, how to surface information, and how quickly we get it. Sometimes that means speeding things up — shortening build times or adding logging — but sometimes it means slowing down on purpose. Taking time to explore step by step, to add more observability, or to walk through a workflow carefully can reveal details we’d miss at full speed.

The goal isn’t just to get feedback faster — it’s to design feedback that accelerates learning.

Closing Reflection

Software testing, like lifting, are practices that can look easy from the outside. To someone watching, it may seem like a tester is just “randomly pressing buttons.” But underneath, there’s intention: forming hypotheses, observing carefully, connecting signals, and adjusting based on feedback. Sometimes that means repeating a scenario to learn more, sometimes it means trying a completely new approach.

Of course, there are huge limits to the analogy. Deadlifting is more of a physical skill where I train my body to move well and stay strong. Testing is a cognitive skill where I train my brain to form , notice patterns, challenge assumptions, and explore risk. But the small parallels circles around the need for feedback: both require listening carefully — to your body or to the system — and using that information to adjust.

When feedback is fast, you accelerate not only your progress but also your ability to adapt. Whether it’s correcting a mistake, fine-tuning a movement, or exploring a new path, quick feedback shortens the time between action and adjustment. It gives me the ability to spot patterns faster.

And that’s the real carry-over. Under the barbell or inside a product, progress comes from designing and using feedback loops that are fast enough to guide the next step, diverse enough to reveal different perspectives, and deep enough to provide value.

Deadlifting and software testing look completely different on the surface, but at their core they are both ongoing practices of learning — ways to continuously explore, learn, adjust, and improve.

On a side note I actually don’t do conventional deadlifts any longer.

The Triangle of Perception: Why We See The Need for Testability Differently

Posted on by
2

Rethinking Testability Part 3 – A series of blog posts based on my talk Improving Quality of Work and Life Through Testability


Rethinking Testability Part 1 – Testability is about people, not just code,  Part 2 – Poor Testability is Everywhere – but we don’t always see it

Japanese anime styled picture. A triangle in the center of the picture. To the left a girl with brown long hair faced towards the triangle and in dialogue with black haired guy to the right of the triangle.
Triangle of Perception

Same same but different

Two people can work on the exact same system and what seems to be the same problem— and yet live in completely different worlds.

I learned this many years ago—I was working with a developer, asking to improve the logs to help us catch subtle problems. But we saw logs very differently: for me, they were essential; for him, they were occasional – which made him question the investment and the time needed to improve the logs.

As a tester, logs were really important to me. I relied on them not just when something was obviously broken. I needed that observability before anything failed. It helped me spot anything weird—things that might not be visible through the UI.

For the developer, logs were something he dug into after a failure—part of troubleshooting a known issue. Logs were helpful, but only needed now and then.

We weren’t disagreeing on whether logs were useful.
But how often we needed logs and how we used them, what we used them for – shaped how we saw the need for investing in better testability.

Three Factors Shaping The Perception of The Need For Testability

An animated picture in black and white with a triangle in the middle. To the left you can see the shadow of a person with short hair. On the right the shadow of a person with long hair. They both face the triangle. On top of the triangle is a text- view of testing - inside the triangle is a text - Perception of tstability. In the left corner of the triangle it says - usage of the system. In the tight corner of the triangle it says - frequency of interaction
Perception of Need for Testability Triangle

Over time, I started noticing a certain pattern.
It seems like different people’s perceptions of the need for testability are shaped by three main factors:

  1. Frequency of interaction — How often do you work with the product? Daily? Occasionally? Rarely?
  2. Usage of the system — How do you interact with the product? No matter if you are building it, testing it, observing it — When you do work with it, are you going deep into the system or just skimming the surface?
  3. View of testing — Do you see testing mainly as confirming known behaviors, or as exploring the unknown?

When your answers to those questions differ, your sense of what’s “good enough” for testability will differ too.

Confirmation vs. Exploration

An animated picture in black and white with a triangle in the middle. To the left you can see the shadow of a person with short hair. On the right the shadow of a person with long hair. They both face the triangle. On top of the triangle is a text- view of testing - inside the triangle is a text - Perception of tstability. In the left corner of the triangle it says - usage of the system. In the tight corner of the triangle it says - frequency of interaction
Perception of need for Testability

I’ve noticed that the third factor — how you see testing — is the one that changes the conversation the most. Note – I am clearly polarizing and exaggerating the views, to make the distinction more clear.

When someone sees testing as confirming expected outcomes, they’ll judge testability by how easily they can check the known. In my experience it seems like the symptom of this is a huge focus on testability for automation.

But if we see testing as exploration—about learning, discovering, and questioning—then what we need from testability will be different.  We need to support serendipitous exploration—being able to notice something interesting and then quickly dig deeper without friction.

Unfortunately, most organizations I’ve worked with lean heavily toward optimizing for confirmation and verification, maybe because it’s easier to measure. Exploration often gets left behind and when that happens we risk missing the bugs that really matter. For more on this topic see my post on Testing Beyond Requirements.

Why This Matters

When someone nods along as you talk about improving testability, it’s worth checking:
Are they picturing the same thing you are?
Or are they imagining something completely different?

That shallow agreement can be dangerous — because it hides the fact that you might be solving for entirely different problems.

Rethinking Testability Part 1 – Testability is about people, not just code,  Part 2 – Poor Testability is Everywhere – but we don’t always see it

Testability Is About People, Not Just Code

Posted on by
4

Rethinking Testability Part 1

Poor Testability

I’ve lost count of the times I’ve seen similar scenarios play out:
A tester — or sometimes a developer — spends hours just getting the system into a testable state. By the time everything is finally configured, they’ve got maybe twenty minutes left to actually do the testing.

They don’t complain.
Nobody on the team does.
It’s just how things are.

But to me, that’s not just a scheduling hiccup or a minor annoyance.
It’s a symptom of something deeper: poor testability.

The Narrow View That Holds Us Back

In my experience, when “testability” comes up in technical discussions, it’s almost always framed in narrow, code-focused terms.

The ISO 25010 standard, for example, defines it as:

“The degree of effectiveness and efficiency with which test criteria can be established for a system, and tests performed to determine if they’re met.”

It’s not completely wrong — but it’s incomplete.
This definition treats testability as something the system has, as if the only point of testing is to check that known expectations are met.

But testing is so much more than that. It’s about learning. It’s about discovering things you didn’t expect. It’s about questioning assumptions and exploring risks before they turn into real problems.

When we define testability too narrowly, we risk building systems that are easy to check but hard to learn from. And that’s where the real damage happens!

A More Human-Centric Definition

Dimensions of Testability

After 25 years in software development, here’s how I see it:

Testability is how easy it is for a specific person to test a specific product in a specific context.

That single sentence changes the conversation.
It forces us to look beyond the code and think about:

  • Who is doing the testing, and what skills and knowledge they bring.
  • What tools they have, and how easy those tools are to use.
  • The culture of the team, the pressures of deadlines, and the development practices in play.
  • The architecture and purpose of the product itself.
  • …the list continues. For a deep dive into the dimensions that affect Testability – have a look at my previous work on testability.

These aspects aren’t fixed. They shift over time — even within the same team. What feels smooth and straightforward to one person might feel painfully slow to another.

That’s why I don’t think testability is about speed. It’s about effort — how much effort it takes for this person, in this moment, to make real progress in testing.

Why This Matters More Than You Think

When testability is low, it doesn’t just slow down releases or make bug-hunting harder.
It drains energy. It discourages curiosity. It not only undermines confidence in the product but may also create a dangerous illusion of reliability.

In my experience, many people look at a green test suite and assume everything’s fine. But they don’t talk about what it took to get there.

Tests passed—but only after multiple retries.
Or the environment was unstable, so corners were cut.
Or the system was too painful to set up properly, so we didn’t test very deeply.

That struggle—that story—rarely show up in the report.
It’s all green.
It’s an illusion based on data with no context.

I’ve seen skilled testers spend most of their day wrestling with flaky environments instead of exploring the product.
I’ve seen teams skip entire categories of tests — not because they didn’t care, but because the setup was too painful.
I’ve even seen burnout happen not from impossible deadlines, but from the constant grind of fighting the system just to do the basics.

The hardest part is that burnout doesn’t stay at the office. It follows people home. It affects evenings, weekends, families, and mental health.

Poor testability might look like a technical issue on the surface, but its impact runs much deeper.

So – Improving testability isn’t just a technical win. It’s a human one.
It changes how smoothly we work, how quickly we learn, and how confident we feel about the results we’re getting.

Where to Start

If you want to improve testability in your team, start by looking beyond the code.

  • Talk about people, not just systems.
     Ask: Who’s testing this, and what do they need to succeed?
  • Look beyond speed.
    Faster isn’t always better. Less friction is better.
  • Measure the effort, not just the output.
    Track how long it takes to get into a testable state, how easy it is to observe and control the system — not just how many tests pass.

Testability is a reflection of how we work.
When we improve it, we’re not just improving the code — we’re improving the whole experience of building and testing.

Rethinking Testability Part 2 – Poor Testability is Everywhere – but we don’t always see it