Rush B in software projects

software development, personal experience, agile, and testing
a screenshot from Counter Strike Global Offensive videogame from 2012
Counter Strike: Global Offensive, 2012

TL;DR: the “blazing fast” mindset of “we’re too fast to test/fix our stuff!”-type of rushed software projects: why it’s a bad idea, and why it’s also a conscious business risk and what it may lead to.

(UPDATE, 4 February 2020): For those of you who have never played Counter Strike or any similar video game, a small explanation of what it’s all about (if you’ve played the game, you can skip this part). Picture two opposing teams of about 5 people each (one is the “Counter Terrorists”, another is the “Terrorists”). A “typical game” of Counter Strike unfolds through a series of rounds, the wining team is decided once they won about 16 rounds. In a round both teams have a few minutes to traverse a location, called a map, and plant a bomb (or prevent it from being planted in the case of Counter Terrorists), while at the same time having to face opposing team members they encounter in shootouts. The map usually has 2 different sites (site A or site B) where the Terrorists can plant the bomb, so the catch is that each team has traverse the map in such a way as to further their chances of a successful attack or defence, and adapt to the other teams moves. This oftentimes requires a lot of communication between members of the same team, as well as skill and practice of each member to handle shootouts, and it’s in the interest of each team to position themselves on the map as best as possible, to control certain corners or vantage points, or even to cover the bomb sites entries.

I was a “late adopter” of the game Counter Strike. I started playing the 1.6 version of the game at my parents house surrounded by friends and my brother, we hooked up a lot of ethernet cables, an old router, and a few laptops and desktops. This was at the same time that the Source engine version of the same game was already out (like I said, late adopter).

Every Counter Strike player after putting some time into the game starts adopting it’s indigenous jargon and becomes fluent in its tongue: “Rush B!”, “Bomb drop!”, “Three Long!”, “Middle!”, “Double doors!”, “Tunnel!”.

The jargon was (and still is to this day) usually just two or three words, shouted across a microphone, or angrily typed into the in-game team chat. Vulgar in appearance, but expressive with every silable. Even if we’re not a professional player, we quickly understand that oftentimes, to increase our chances to at least be in a position to win the round, and ultimately to win a game of Counter Strike, we need to be blazing fast at coming up with an attack plan, or a defense plan, and then communicating it and acting on it. There’s a reason why angry kids in other parts of Europe shouted “RUSH B!” and not “Excuse me good sir, kindly move or walk over to the point in the map signaled with the letter B!”.

Every player in a round or a whole set of rounds was conscious that speed, skill and being flexible ultimately changed the course of things, and to be honest, that is not that different from delivering a software product.

Those of us who work in the software business and have been players or actively play shooting or strategy games that require collaboration (or real life team sports for that matter), inherently understand this similarity. What on the other hand we sometimes miss out on is: being conscious about it.

Yes we have to deliver something fast. Yes it’s nice that what we deliver is a “quality product”. And yes, being fast comes with its trade-offs. But somewhere along the way we incur into the same mistakes of losing teams in a shooting game like Counter Strike.

Being blazing fast

Everyone that has been long enough in the software business is witness to an estranged version of fragile, for example:

There’s a reason that I marked out “Customer satisfaction”, “valuable” and “working” - it’s because in practice they’re some of the first things that end up being neglected. The aspiration to be super fast at churning out anything, even if that something is horse droppings, becomes the dominant dance everyone has to take part in, and often no one can explain why, apart from the tipical words of order “we have to be faster than our competitors”.

But, like in a round of Counter Strike - speed on its own is not a guarantee of victory. It doesn’t matter if we’re the first to reach a give position on the map, if once we’re there, we’re poorly prepared or equiped.

The best teams in the game understand that they’re as fast and as skillfull as the slowest of their teammates, so they adapt: the weakest link becomes one of the most important frames in the game, the team adapts their attack or defense so that their shortcomings can be less of an exploit entryway for the enemy team.

In the software world, I ponder that this kind of “good” team is usually transcribed in some of these, identifiers:

Testing for example is one of the very first things that is left out of the party in favor of “blazing fast speed”. It’s not a surprise to be honest, and it’s quite simple:

There’s a breakoff point where speed and our ability to learn, investigate, explore and play are not hand in hand. If learning or play are not invited to the party - proper testing is of course not invited too.

The same applies for “motivated individuals”. We see the exact same thing in a losing game of Counter Strike: “We’re so fast, we should be wining, but the other team, while slower than us in nature, is crushing us in the end!”

The slower and wining team isn’t necessarily slow either - but their ability to learn is always side-by-side with speed, and always adapting to the slowest or weakest of their elements. We got crushed because the other folks are

  1. (Usually) more skilled than we are;
  2. Actively observing, adapting, slowing down, speeding up, …

“Ah, but what you’re saying, this is all very idealistic and fantasy. The real world is the real world, we can’t fool around, we have to be fast! If you can’t keep up… well, you have to keep up.”

Can’t keep up with the speed

Let’s visit for instance the point of “Testing not being invited to the party”. Everybody who tests, or has a testing component in their projects will tell us that, yes, oftentimes testing “can’t keep up”.

For the proponents of Rapid Software Testing, the idea that we as Testers can’t keep up with development, is itself a test result: development is going faster than our ability of learning about the product through exploration and experimentation. And this is a business risk we’re taking, whether or not we’re conscious about it.

What this really means is: we could develop in a way we understand the quality of what we’re making, we could slow down and do reasonable testing while we develop, but it appears our competitors are faster and don’t mind shipping without doing proper testing.

“We’ve got to release today, because we can’t waste another day; people are just rushed - people want these features for yesterday.”

The “competitors are faster” shout is in my experience a false-start. It’s a carrot in front of a donkey. A competitor might appear to be faster, but the noticeable speed by itself may be meaningless. What does it matter if the competitor is fast, if we’re missing out on both the big picture, that maybe they have the skill in to be faster, and the internal picture, that they might have adapted their development process so that weak spots become covered?

“The neighbor’s yard is prettier than mine”

To be honest, it’s not that simple to just assume that someone else’s apparent speed for them meant cutting corners on things like Testing. We have to look into speed deeper.

Let’s pick an example: If you’d tell me “I know for a fact our competitor doesn’t do unit tests (aka. checks) and they came up with a wonderful product, so we’ll skip doing unit checks, and now that we think of it, we’ll skip Testing, we’ll just hire someone later to assure quality into the product”… I’d tell you that’s stupid. For many reasons, I’ll elaborate on two:

Let’s pick another example: “Well, the market’s top corporate messaging software doesn’t do testing, they just code some checks, and then they put in some memes or cute puppies on their error pages”. Yup. Top software. Keep at it then champ! It’s an awesome pathway, Wonderful blazing fast developed software that:

Slow down, wrapping up.

I feel sick to write this, mostly because Agile is as useful to me as Jedi sacred texts are to someone who sees through the Jedi Council hypocrisy, but if we look for it, “Agile doesn’t say” that we need to be ultra fast, so testers better catch up, in fact, the manifesto says something quite different, in its eigth principle, that people with “Agile” in their job titles often forget:

Sustainable development, able to maintain a constant pace

Sustainable development. Development may need to take in a lot of risk, both known and unknown risk. But when we decide we’ll develop faster than we can reasonably test, or that we don’t care if the individuals that build the product are motivated, sure, we might be fine for some time, but it’s a risk that the business is undertaking, and it should be a conscious one.

The more unsustainable the development process, the more we’re going to experience embarassing bugs in the field. And we’re talking about the kind of bugs that not only breed nuisances but in some cases destruction and death of its end-users.

Slowing down doesn’t mean we’re setting ourselves up for losing, but it gives us the headspace to be alert, to adapt, to cover our weak corners. Once we’ve built our team up to be adapted, sustainable, and reasonably fast, then by all means: RUSH B!

Thank you for reading. Feel free to reach out to me with comments, ideas, grammar errors and suggestions via any of my social media. Until next time, take care!