Can You Make a Bug on Purpose?

We, developers, come across bugs regularly, it's just part of our job. Therefore, at first glance, the question “Can you make a bug on purpose?” may seem banal - “Yes, of course, I can write a bug.” However, if you think about it, everything doesn't seem so obvious anymore.

The fact is that the bug is not the same as broken code. A bug is an error, a flaw in a generally

working program.

What’s the problem?

The world is known to be well described by mathematics formulas. And the formulas are actually the algorithms. Therefore, if we were able to describe some phenomenon mathematically, then correcting the resulting formula so that it only sometimes gives the wrong result is a non-trivial task. Nevertheless, it’s not time to despair. Boundary conditions may come to help us here. We have all seen these if index == 0 {…} else if index == n-1 {…}. There's always something wrong with the boundaries 🤷‍♀️. So, let’s note the first idea for creating a bug - ignore edge cases.

In general, iterating through arrays is a storehouse of potential bugs. And the most common of them is index out of bounds. If you have never stumbled upon such a thing, you have never coded. Unfortunately, this bug is so popular that people began to write safe wrappers for arrays, something like array[safe: index]. So today, your colleagues will hardly approve any code without this thing. You can try, but it's unlikely…

Prevalent bugs include stack overflow. A recursive algorithm can recur infinitely when there is no exit condition. Recursion seems optional here - write while true, and you're done. However, again, the popularity of the bug is playing against us. The developers are well aware of the potential problems of endless loops, and their eyes will definitely catch on to something like this at the code-review 👮

To still push your insidious plan into production, try using a global variable for exit conditions and quietly change it from the outside.

var coditionCounter = 0;

class A {
  func foo() {
    while coditionCounter < 10 {
      coditionCounter++;
      B.boo();
    }
  }
}

class B {
  func boo() {
    coditionCounter--;
  }
}

General advice

It's funny that even ChatGPT refuses to help when it comes to writing bugs. Maybe I just need a premium subscription… 🤔

Being on the bright side, AI offers a set of general rules that contribute to writing bugs-free code: сode in small Increments, follow coding standards, write unit tests, and bla-bla-bla. We can try to do the opposite thing - write spaghetti code and forget about SOLID. However, this way, we lose control over all the code we write. Instead of an elegant pinpoint weapon, we get unmanageable chaos, which will conquer our program.

When solving the problem of creating a bug, it is worth determining the subtasks. First, we need to come up with some rare edge cases. Secondly, we need to disguise the bug as regular code so that it passes the code review. Thirdly, we have to blunt the attention of the QA department. Fourth, don't get caught right away. But this is already optional.

My general advice is as follows (and you share yours in the comments):

• Manipulate the access level. To double back, change the values of important parameters from the most unexpected places. Do this through several classes as if you were a VPN.

• Implement some unexpected logic in the child class. In short, break the L principle in SOLID.

  class A {
    func decrease() {
      x--;
    }
  }
  
  class B: A {
    override func decrease() {
      x++;
    }
  }
  
  

• Hide your insidious changes in bigger functions. The more lines, the better - get lost in the crowd.

• Use the same principle in pull requests. In a small PR, the probability of being noticed is higher.

• Try to break the bug into parts and put them in different pull requests. If possible, then also to different reviewers.

• Find the weaknesses of your QA and win his trust. Or distract them with conversations during the check.

By the way, have you heard of Heisenbug? This is a bug that disappears or changes its behavior during research/debugging. Like Schrodinger's cat. Perfect if the fix issue will not be assigned to you.

You can

Believe in yourself! History knows examples of when a bug was admitted to production in very serious companies.

Ariane 5 Flight 501: One of the most expensive software bugs occurred in 1996 when the Ariane 5 rocket, carrying the Cluster mission, exploded just 40 seconds after liftoff. The failure was traced back to a software bug in the rocket's guidance system.

NASA's Mars Climate Orbiter: In 1999, NASA lost the Mars Climate Orbiter due to a software error. The software used imperial units (pound-seconds) instead of metric units (newton-seconds), causing the spacecraft to burn up in the Martian atmosphere.

Moreover, some bugs can become features, like a wall-jumping in Mario or Mahatma Gandh behavior in Civilization…probably.

Developing a bug is the ability to think through your algorithm and anticipate possible problems thoroughly. So, even if you have no reason to leave a bug in the code, it's still worth considering.