We always say we don’t have enough time. Then something like our corona crisis happens, and we have a lot of it in remote work time. I mean, without all that pesky meetings, and 16 coffee breaks a day, we have a lot of time. So what do we do with it?

We still need to work on the important stuff.

Some of us have it easy. We get a list of tasks to do and go do that. That is, we assume other people see the whole picture (our product owner, our team leader, or their manager) and they decide what’s best to work on first. Which works well enough in the beginning.

Then things start to be a bit blurry. As we disconnect from the team and remote work for a longer time, we start to build our own vision of what’s more important.

We start to go off track. We gamble, even if we don’t think that’s really gambling, we’re just making decisions. When we find out, it’s too late. We have wasted time working on something less important, or now need to catch up.

The consequences of these decision include conflicts in the team. I thought that you’ll be ok getting feature X by next week. But you’re ready for integration for the last 3 days, wondering how I don’t see what’s really important. It may be better that we’re kept apart.

And that’s in a tidy environment. If work is messy around the office in regular days, you can see how things just fall between the cracks with remote work.

So what can you do?

• Communicate more. Create more opportunities to discuss who’s working on what and who is expecting what when. (I’m pretty sure that’s real English)
• Continue doing daily meetups. They make more sense when people don’t see each other all the time.
• Visualize tasks, blockers and priorities. Use the tools you have or find better ones (Looking at you, Jira)
• Define a sprint goal (yeah, that thing from Scrum that Jira forgot). If someone’s wondering what should be done next, that’s the guiding light.

I can help you work on what’s really important. And that’s really important. Register for my First Aid Kit program.

My Sister works in an online gaming company. She has a lot of work these days – people stay at home, got plenty of time, and play online. Which brings me to another topic that slows remote work down. Gambling.

It’s not really gambling, but it’s close to that.

Most of our work in and out of remote mode, is making decisions. How to write the code, which aspects to test, what to do next. But with remote work, we don’t have guidance, direction or availability for information, it becomes harder, because now, we’re gambling with decisions.

There are basically two groups of people: The do-ers and the wait-ers. Usually we don’t see big difference but the remote situation makes it more extreme.

The do-ers make decisions by themselves, moving forward, consequences be damned. Sometimes the decisions work out well, sometime not. But in our remote work situations, it usually takes longer to get feedback if the decision was the right one. If it wasn’t, it takes even longer to go back and fix those consequences.

The wait-ers, usually don’t take initiatives, and move slower than the do-ers. When there’s not enough information to make decisions, in our remote work, they delay implementation of decisions, which obviously slows work down. But even more so, when NOT making decisions is not reported (which is easier to spot when everyone is at the same place) – blockers are not resolved, and work slows down.

So what can you do?

• Communicate more. Create more opportunities to discuss these issues
• Create an issue board to visualize blockers, and use it not just for regular blocker, but also decisions waiting for solutions
• Make more demos and early. Demos show decision we’ve taken. With more frequent demos, we’ll find problems early
• Award making decision early, and don’t punish “bad decisions”. We want people to make more decisions early.

These are just a few of the things you can try. I can help with the implementation bits for your. Check out my First Aid Kit program.

Once more unto the breach, my friends. Once more.

This time I took the Test Maintenance presentation to Tel Aviv. The presentation is right there below.

Test maintenance is something nobody loves doing, but everyone must. The presentation is about what we do when we’ve accompanied lots of tests, some of those tests are old, some new tests we’re writing. How to organize those tests, add tests in a smart way so people can find them. The we looked at different types of tests and smells in them and how to fix them.

The one-hour presentation is a very compressed version of a full-day workshop on Test Maintenance. That’s right, you can have the “Test Maintenance” workshop experience, including many hands-on exercises in your workplace, on your code.

Check out the workshop page.

Making the “Zen and the art of Test Maintenance” workshop into an hour long presentation, I made way north on a dark and stormy night. It was lovely to see old and new acquaintances.  I saw a nice demo of  new-ish open source tool called Oxygen, presented by Nick Dimer. Thanks for the organizers of the meetup, Nitzan Goldenberg and the hosts in Bar Lev HiTech Park. And to Bar Gothertz for the photographs like the one on top!

This will come in soon to the Israeli center soon. And as always, if you want to experience the full workshop, test refactoring galore, let me know in the comments.

Here are the slides:

Last week I came back from Let’s Test South Africa. As always, Let’s Test stood up to its name. It’s a small conference, with a lot of hands on-learning, and a focus on community. It’s about testers meeting other testers, learning, and feeling good about it.

My workshop “Zen And the Art of Test Maintenance” went great. (See picture for testers working on refactoring tests.) Unfortunately, immediately after the session the bug I apparently picked up on the plane hit me hard. I spent the next day either in bed, or trying to keep awake at sessions I didn’t want to miss (Hi Paul Holland!).

I’ve also re-met friends (Simon Berner, Gerlad Mucke, Beren van Daele, Regina Martins,  Joanne Perold, Elizabeth Zagroba and Paul Holland ) and made new ones. I want to thank especially Alison Gitelson for drawing the poster for my workshop (the main picture on top). And to Louise Perold and the rest of the crew for an awesome conference. I’ll be coming back. Healthier.

After that, things got better. I got back to eating the awesome food provided by the conference. Then I became a tourist for a couple of days, plus going to a karate class in a local dojo. I felt a lot better then.

Anyway, that’s 2019 testing schedule. I got one more training on agile and estimation this week at Sela Developer Conference.

Then it’s on to 2020. I have a good feeling about next year. Stay tuned.

Last time, I gave you the short-short version of thermodynamics. We talked about how entropy grows rampant, as well as creating waste in the system, if it doesn’t have constant energy input.

Let’s get back to technical debt. The technical debt metaphor has two parts: First, it slows us down in the long term. The second part is that it can go away – for a price.

You can already see the resemblance to our energetic system. The code has growing entropy. Chaos, or our inability to control the code, keeps growing. The chaos creates energy-wasting traps, and we deliver slower.

What are these traps?

If we don’t have tests, we tend not to refactor. If the code is not readable, we’re very cautious about adding new functionality. If the code is one giant method, we tend to add parts of the new functionality within the giant method, otherwise we risk breaking stuff. These are the time-sucking traps we need to avoid, instead of going forward fast.

So the code grows, laying more energy traps for us, which slow us even further the next time we go into the swamp.

We need to invest energy in the system to remove the traps. We need to take care of the code – spend time in refactoring, improving it, so the next time the swamp is easier to navigate through. In the long run we sustain velocity, instead of losing energy. The swamp gets clearer, but never gets clear.

The second part of the metaphor is where I think it fails – since it’s not really a loan, we’re never going to fully repay it. There’s not going to be an endpoint where it is repaid. There’s not going to be a single point of repayment. There’s always something more important to do. And since we never stop and “repay it” – we’re stuck in a downward spiral.

In the real world, the best we can do is keep things under control the best we can. We do that with clean code, refactoring, adding tests and code reviews and design reviews. Those reduce the energy traps, and maintain sanity. Entropy does *not* grow unchecked. But since entropy wants to grow, we will keep doing the work, putting energy in, but there is no end in sight. Or at all.

In some situations we believe we can repay the loan fully. We later discover we got to a “good enough” point. If we continue after that, the way we worked before, we see that the “good enough” point is not only good enough, it was just a temporary mirage.

I’ve stopped using technical debt as a metaphor, because it doesn’t correspond with reality. In real life, the business people have no problem sacrificing long term costs for short term gain. The loan can never be repaid.

Instead we should continuously lower the code entropy, get rid of the black holes, and putting energy, into clearing the code swamp.

Goodheart’s Law states that when a metric becomes a goal, it is no longer a good metric.

I don’t know when technical debt became a metric. But SonarQube calculates and reports it as such. If this calculation is correct (you must be scratching your head right now) people may assume that once they eliminate it, according to the calculation, they are debt free.

Of course, they are not. The technical debt metaphor (yes, there’s no real metric) was supposed to help explain the idea of comparing technical tasks to feature tasks, which are considered more valuable. Technical tasks, like adding tests, refactoring and simplifying the code and architecture don’t have an immediate value, compared to “real” features (I know, it’s perceived value, not necessarily an  actual one). But not doing the technical stuff makes adding feature value slow in the long run. The deeper the debt, the slower you get with the new features.

Business people, however, don’t understand how “not working on features” helps features get built. Organizations that have evolved beyond that don’t require technical debt use, since they already understand the impact.

I don’t use technical debt in my vocabulary anymore. So I needed an alternative. When I studied engineering I took a couple of courses in thermodynamics. Little did I know then, how well they relate to coding.

Ready to learn a bit?

A system has different kinds of energy in it. They can be kinetic, electrical, or potential energy which can transform into other types energy. Energy can be transformed into “work”. In physics, “work” is the implementation of potential energy. In a closed system, energy is conserved, but as we all know, no system is really closed, and therefore every system cannot conserve all its energy, unless we add more energy into it – like heat it, charge it, throw it real fast. You get the idea.

Next, there’s entropy. Entropy is basically the chaos in the system. Another way to look at entropy is from a perspective of energy. Entropy is the amount of energy that we cannot use to do work. We can’t transform it into useful kind of energy, because it gets wasted.

Now, if left unattended, given enough time, chaos takes over. In energy terms, we lose the energy, since it cannot be conserved. Entropy grows, unless we put more energy into the system.

Reminds you of something?

Part II is all about energy and entropy in code.