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.

This series is about the origin of bugs. Although they did not come from an apocalypse, they are sure leading us towards it.
Part I	Part II	Part III
Part IV	Part V

We’re getting there. Here’s the final nail in the coffin: We are bad at translation and unfortunately, we do a lot of translations.

In a typical application development, we’ve got a user who has a problem:

“Why can’t I see the content when I open the app?”

The business person translates that into a vision:

“Of course, that makes sense. Every time the app starts, it should show the content”.

He then turns that into a requirement:

“The start screen should look like this, and the latest content should be shown”.

The architect takes the requirement and says:

“When the main module loads, it should get the latest data from the database. Oh and let’s separate  it into a new micro-service”.

The developer (I know I’m stereotyping, but role-playing is fun) gets that from the high level design, and writes a detailed design for the code saying:

“For performance reasons, when the new data gets there, it is also cached for other retrievals. Oh and let’s make that two micro-services”

On the other side of the table, our tester looks at the requirement and says:

“I’ll need two staging environments, one for testing in a standalone configuration and one distributed, I’ll load the data differently each time, and I expect every time to see the newest data when I reset”.

Just a short example. Of course, after all this is release, the user says:

“Well it works most of the times, but not always. Why can’t I get my content?

Communication is hard, especially when we’re working cross-domain working on complex issues. We don’t speak the same language. Whenever there is a translation error, two bugs get their wings. That’s how the Tower of Babel started.

To summarize: Bugs happen because we are not good at what we do, we don’t admit it, we don’t communicate well, and after all that, we still relying on pure luck that the thing would work.

How do you fix a bug? You understand what the correct behavior should be, plug the hole up stream and check that it works now, and again, and in two days – again.

How do you fix a buggy process? The same way.

 

This series is about the origin of bugs. Although they did not come from an apocalypse, they are sure leading us towards it.
Part I	Part II	Part III
Part IV	Part V

On to the next issue: We trust in the “others”. Way too much.

Have you ever considered how much of the code we actually write makes of the whole application?

I mean, let’s start with hardware. Computers, wires, antennas, satellites. We use them as part of our solution, and they are not even code. Then there’s servers and routers. There are runtimes and libraries. There’s open (remember heartburn?) and closed code. There’s code that’s been running for fifteen years that nobody can read, but works in production. And then there’s our code that integrates with all of them.

Oh, our code doesn’t really run. There are the compilers that turn into into runnable bits.

So how much of that whole thing does our code weigh?

Let’s be generous and say 5%. Yeah, the “others” are not what runs between our pieces of our code. Our code IS really the “others”. And we don’t only trust everything out there, we don’t even think about those things and how they work.

Until they don’t, but then, once we upgrade/reintegrate/replace them, we usually forget and move on to the new trendy framework that must be better than the old one because… trust?

Our view of testing is limited too, because of our optimistic assumptions that “these things work”. Bugs come out of the cracks and they surprise us every time, because we didn’t even get a flashlight.

Our concept of building software should be a skeptic and cynical. The idea of standing on the shoulders of giants is a good one, as long as the giants are stable.

We’re a pretty optimistic bunch. And optimism gets us every time.

When were you last surprised (in a bad way?)

This series is about the origin of bugs. Although they did not come from an apocalypse, they are sure leading us towards it.
Part I	Part II	Part III
Part IV	Part V

We’ve looked at a couple of excuses to where bugs come from, now let’s dig deeper.
And we’re going to start with something that’s hard to admit: We don’t know exactly what we’re doing.

The best of us already know that, and the rest of us have not figured it out yet. If you’re offended, I’m sorry, but hey, if we knew what you were doing, it wouldn’t be that hard, would it?

I used to think I know everything. And then I understood I don’t, but thought that even if that’s the case, I can learn everything. And if anything happens, I can control it.

I’m better now.

Our skill level plays a part in making mistakes, obviously. We are less prone to small stupid bugs. We think.

And it’s our hubris that tells us that bugs are caused by other, inferior people. We won’t make the mistakes that “they” do.

Nope. We still make mistakes. Big and small ones.

And I’m not talking about just developers here, if you haven’t figured that out yet. Anyone and everyone on the value stream is not as good as they should be. Nobody is exempt from contributing to the bug pool.

Misunderstanding, using the wrong tools, wasting time on Facebook and working on magnificent plans that never pan out – We still don’t do our job well. We are not focused, we are not weary of the risks, and don’t do our best to get remove those pesky bugs.

Funnily enough (or not), agile development (especially eXtreme programming) has a couple of cures for that. Even “old” methodologies had those.
Processes that focus on delivery, quality and feedback. TDD, clean code, design, exploratory testing, design reviews, code reviews. There’s a lot more we can do.

We’re still learning how to be better, and we should be better at that too.

What are the things you know you can improve right now?

This series is about the origin of bugs. Although they did not come from an apocalypse, they are sure leading us towards it.
Part I	Part II	Part III
Part IV	Part V

While we’re on the subject of favorite excuses, let’s talk about a couple more I got.

It’s not my fault! pic.twitter.com/p2jeziwFpt

— James Grenning (@jwgrenning) July 22, 2019

It looks more like an escape pod than a bug. Ironically, “don’t look at me” does the exact opposite. It looks very unprofessional. But let’s dig deeper.

We need to ask, how this became a “who”, rather than a “how” thing. Even if you isolate everyone in the process, and have them contact each other through taped recording, it would be very hard to prove that the bug is specific someone’s fault. But that doesn’t matter really, is it?

If the organization looks to blame someone, it will find someone to blame. “It wasn’t me” is defensive for a reason, a safety-less culture. Bugs can come from systemic failure. The excuse is just a symptom.

Let’s carry on to James’ second contribution:

This was from long ago, a colleague would immerse himself in a bug hunt, only to return days or weeks later and report: “It was only a typo.”

— James Grenning (@jwgrenning) July 22, 2019

Again, another symptom. My guess it wasn’t a typo.

If it wasn’t, why would he say that? Feeling no safety to take responsibility, acknowledge a mistake, and learn from it – this is probably not a specific someone’s issue. It’s an organizational issue. People tend to cover up. if they are feeling they are going to be persecuted and judged. If it was a typo, using “only” to diminish the problem, gives us a hint on how the programmer might have felt.

The next one I got actually leading to the next post.

“This is a prototype. We don’t need testing.” Then the “prototype” goes to production.

— Kenrick Chien (@kenrickchien) July 23, 2019

Was it really a prototype?
Was there ever a situation where testing (at all, not any more testing) was not required?
Was there ever a first anything that doesn’t need testing?

That’s culture related as well, but needs more digging. In the meantime? Leave some more excuses in the comments. We love excuses.

This series is about the origin of bugs. Although they did not come from an apocalypse, they are sure leading us towards it.
Part I	Part II	Part III
Part IV	Part V

“What do you mean?

When a mommy-bug and a daddy-bug (or any other gender bug) love each other very much…”

Well, that would explain how they multiply. But seriously, what gives? It’s 2019 (I’m pretty sure in ten years time it will be the same). How come we are still crashing systems, inviting hackers in and miscalculating money exchanges? Shouldn’t have all of those supposed to go away?

So here’s my rant, starting with a couple of excuses I hear.

“The things we build are complex”

That is true. I think it touches on the root cause, which I’ll talk about later. Yet, we also built software that took people to space and beyond in the 60s and 70s with stone age tools and with no debuggers. From the outset of computing we’ve been building complex software. Why is it only now we need so much testing power, and it falls so desperately short of the actual quality we hope for?

“We don’t have time to test”

That is true. We don’t have enough time to code too. We just hack things together, because… because the business says we need it, now, pronto. And the business takes risks, like releasing too early, without testing. So are the business people to blame? The markets? The global economy?
“No time” really means mismanaged time. Or mismanaged priorities. How much code do you produce? Now, how much of it is in use? Wouldn’t it be wiser to focus on building things that work, (as in test them, really test them) rather than twice as much code that only half works? Wouldn’t it make sense to write lean, clean code that does what we need now, rather than prepare it for features that may never come? Features that won’t be used?
We may not have time, but the truth is we don’t really use the time we have as we should.

“We don’t know everything”

That is true. Spoiler alert: We never will. What we learn tomorrow, will contradict what we built yesterday. Then, at the time we’ve learned of the discrepancy, yeah, there is a “bug” there. It gets fixed immediately, because it’s important, and suddenly there is no bug, right? Funny isn’t it, that what we perceive as a bug has a life expectancy. Only the non-important ones get to live longer.
However, most of them are not “it should not behave like this” kind, rather “it just doesn’t work”. A lot of the bugs are not a requirement surprise, they are mostly quality surprises. Yes, we should explore more. We should also validate and test more.

“The requirements change all the time”.

This is the child of “We don’t know everything” and “We don’t have time” arguments. This doesn’t explain bugs, it just gives them an excuse to exist. We still need to test.

“We don’t have enough testers”

Let me translate it for you: “We have so much code that goes untested”. Or “we don’t know what our programmers are doing”. Or “we don’t understand economics”. It has a ring of true, though. If producing code is a linear-order process, testing everything is exponential. Obviously, we need more testers.

(Maybe instead write more code that actually works? You know, automated tests, TDD, clean code? And maybe do some design reviews and code reviews? Sorry, my inner agile just reared its ugly head.)

The argument is really economic in nature. Developers cost more than testers. So getting a 3 devs  to 1 tester ratio may seem economically viable. As viable as thinking developers producing more code equals product success. Makes sense on a piece of paper. The code quantity, however big, still you know, should work, or it’s a waste of precious developer money. And there are ways to do that. (TDD, clean code, automation, reviews. Sorry, that inner agile again).

All the above things almost don’t really explain bugs. Except for the complexity one. But how does complexity breeds bugs exactly?

I’ll continue next time.

Here’s a bit of news: I’m going to Let’s Test in November!

I’m really excited, for a couple of reasons.

The first is – it’s Let’s Test, baby! I’ve been to the last couple of Let’s Test event in Sweden, and if you haven’t been – that’s a very special event. It’s non-stop hands-on testing. This year, we’re starting at Sunday afternoon, going through the evening (my workshop is at 7pm), and then continue this way until Tuesday afternoon. There’s always something going on, and the community is awesome, receptive, eager to learn and teach.

My workshop is “Zen and the art of Test Maintenance”. It’s going to be shorter than the Test Bash version (2 hours), but awesome in the same way. If you’ve collected, dozens, hundreds and thousands of tests, you feel the maintenance pain. The Workshop teaches how to deal with that pain.

What else am I excited about? It’s going to be my first time in South Africa. I’m hoping to see things in Cape Town, and maybe around it. Hopefully go to a testing meetup. I also plan to visit our local karate dojo, and return a favor after so many years of hosting their visits here.

The final thing is that in Cape Town I’m going to run a new public workshop. It’s intended for developers who want to write better code, and for testers who want to help developers write better code. Details coming soon.

It was my first time at ExpoQA, and I had so much fun. I’m definitely coming back next year!

Here are the slides from my “Spock” Talk on the Groovy unit testing framework.