I haven’t blogged since July, and since then I have taken part in a Ministry of Testing AMA on blogging, in August.

The conversation flowed into a thread on the Ministry of Testing Club

It was a really good session, but I was filled with a little bit of imposter syndrome as I hadn’t blogged much.

Life can be pretty cyclical, and this isn’t the first time that I have found myself in a bit of a rut with writing blog posts.

But a recent series of unconnected events led me to this post today.

1. I have been getting my house ready to sell
2. I was starting a new job at a start-up
3. Stu Johnson put out this tweet

I'm a million years old https://t.co/gchP2lN8HG

— SᴛᴏᴏOOOᴏᴏ👻 (@wildtests) October 2, 2020

These three things got me thinking about lessons that can be learned from the past, current struggles and most tenuous of all ‘Everything in its right place’ – track one on the mighty KID A by Radiohead.

---

Nostalgia plays a really big part in my life, my children love me regaling them of tales of the olden days and quite frankly, I enjoy telling them.

Looking back at the past, we can see a lot of things that we can learn from.

We should place a lot of emphasis on learning from our experiences to mitigate things in the future.

---

Firstly, the recent pandemic has afforded me a lot of time at home to sort and organise that which I have not sorted and organised in the past. This is an example of recent historical decisions causing me real problems today.

Houses often come with what is referred to as a ‘box room’, a bedroom that is so small that it barely qualifies as a bedroom. In our case however, we had taken it a step further and merely populated the room with boxes.

Confronted with having to work from home, this was the challenge. Things that previously I could close the door on and ignore, now had to be dealt with.

This reminded me of the last time I moved house and I lost an entire weekend to a garage that needed reorganising to even begin to think about packing, let alone moving.

At that time, I thought you could draw interesting parallels between debt in software development and in what was before me.

Then I forgot about it. But here we are, confronted with moving house once more, it really proves cyclical, and there are lessons that I need to learn.

---

Secondly, I have recently started a new job at a start-up. Before I began, I once again became nostalgic.

Nostalgic about all those anecdotes I have carried with me.

Thinking about all those examples of things done badly, of people having given up, of politics getting in the way, of bad decisions burning us later.

Regrets.

It feels so much worse to look back and regret than it does to look back at failures, or at least failures that I have learned from.

---

Everyone’s favourite Zac Efron movie, 17 Again, has this poignant conversation between the main protagonist, Mike O’Donnell and a janitor in his old High School hallway.

---

So, thinking more granularly, what debts come to mind and what would I hope to do to mitigate those debts going forward?

1. Culture debt
2. Document debt
3. Shortcut debt
4. Later debt
5. Process debt

Culture debt

There are so many examples that I could have chosen for this, but I think frankly the one that I have seen in most places I have worked, to a greater or lesser extent, is the one where you ask why and you are greeted with a shrug and told that’s just how it is, or always has been….welcome to xxxxx.

This has an immediate stink of having given up. I’ve spoken previously about the struggles personally of working where there has been a lack of motivation.

How is it that we get to this kind of culture and how would I hope to work to try and mitigate it?

With a lot of these things this can come from leadership, be it poor communication or micro-management, favouritism or inconsistency.

I know the struggles as someone completely out of the loop and even as a middle manager.

Chris’ culture debt blue sky mitigation: I actually pitched this in my interview, it is to employ the three pillars of empiricism – inspect, adapt and transparency.
What that looks like in practice is spending a lot of time analysing things, collaboratively agreeing on how to adapt and communicating the actions and progress clearly for all to see.

Document debt

I hate the reputation that documentation has, but I do understand it.

I’ve always operated on the understanding that the work we do today should be done for the benefit of those who don’t work on it, be that users or future colleagues.

Working software over comprehensive documentation

https://www.agilealliance.org/agile101/the-agile-manifesto/

Unfortunately I have found this line to have been taken out of context, or paraphrased in such lazy way as an excuse for not doing any documentation.

Chris’ document debt blue sky mitigation: As I mentioned before, there is a time and a place for documentation, so we should look to ensure that we document sensibly, usefully and appropriately.

Company inductions, customer-facing documents, wikis are all useful examples.

Shortcut debt

We do live in a world of instant gratification, quick returns, or buy now pay later.

There can be a culture of this in a workplace environment, there’s a change to the scope of a project, or a project manager needs something now, or a ‘superhero’ is brought in to save the day and get that hacked fix in.

There is something incredibly undermining for a team when that sort of thing happens once, but imagine that happening all the time. I’ve had it described to me before that ‘the business’ have seen what they can get if they scream loud enough they can get what they want.

It is an extreme example perhaps, but think of the damage that it can do. Doing things in a rush, or as a hack can lead to a lower quality product delivered to the customer, especially if there is a perception that the work is now completed, even if not meeting any of the standards or good practices that they team have signed up to do.

Constantly being undermined, feeling that there is no room for development and that the focus of the team is no longer a priority, is so toxic in a work environment.

Chris’ shortcut debt blue sky mitigation: It’s fair to say that pragmatism and compromise need to be employed here. You will perhaps have heard the saying, give them an inch and they’ll take a mile, so once again this is a case of respect and open dialogue is required.

I know that MVP (minimum viable product) exists as a mitigation for this in some teams, but the problem with that can still be that if MVP is met, then it has shipped and we can move on.

I love to employ a blue sky board with the ideal scenarios, then gather requirements and look at how we can iterate on that over time.

Later debt

Imagine paying a visit to your favourite bug tracker and discovering thousands of open bugs and feature requests.

Why are these still open?

Triage? FOMO?

Are we not being honest with ourselves or our customers?

Chris’ later debt blue sky mitigation:

To be honest with you, I have had a hard time with these sorts of graveyards in the past. A bug that will never be fixed shouldn’t sit there indefinitely, that helps no one.

In ADHD, there is a paralysing aspect called Possibility Clutter:

Enthusiasm for the possibilities of the future is wonderful and stimulating, but it can also be troublesome. It leads to a clutter of unfinished projects, a trail of unrealized intentions, and a squeeze on the schedule.

https://www.additudemag.com/too-many-unfinished-projects-adhd-clutter/

Leaving things completely open ended is not helpful. Even if we spend some time looking to see if bugs are still relevant or not over a period of time, if those bugs aren’t going to get fixed, why are they still open.

If a feature request would be ‘nice to have’, but not possible or financially worthwhile to develop, then I guess closing and marking as ‘nice to have’ is a useful mitigation.

But please, don’t keep a graveyard of these things.

Process debt

How do you work? Honestly, this shouldn’t be a hard thing to explain, but you might be surprised how often that actually in the real work.

I have worked as an End-to-End Test Manager (would not recommend) and in trying to understand the end-to-end flow, I found a lot of dead ends of information, undefined (or hard to find) dependencies, role and responsibilities. I was debilitating, demotivating and above all else, blocking.

Chris’ process debt blue sky mitigation:

In Kanban, this is hit head on in The 6 Practices of Kanban:

You can’t improve something you don’t understand. This is why your process should be clearly defined, published, and socialized. People would not associate and participate in something they do not believe would be useful.

When everyone is familiar with the common goal, they would be able to work and make decisions regarding a change that will have a positive impact.

https://kanbanize.com/kanban-resources/getting-started/what-is-kanban

For me, the best way to address this is by using a charter with the whole team to get everything and everyone on the same page.

---

I could have written a lot more about each of these debts to be honest, but this is a long read already.

So to recap or a little TL;DR – my tips for mitigating some debts:

• Three pillars of empricisim
• Document sensibly, usefully and appropriately
• Use a blue sky board and iterate
• Don’t keep a graveyard of tasks you will never action
• Use a charter

---

Blog post title lyrics from: History Repeating – by Propellerheads featuring Shirley Bassey

Find all the songs from my blog posts at this Spotify playlist.