Why Tech is fertile for cheatcodes

… Recap

.

Some people thrive at Tech companies without doing any meaningful work. They cheat their way through. As part of the blog series, we discuss this phenomenon.

Such people use tricks to game the system. We refer to these tricks as cheatcodes.

             

.

In the previous blog cheatcodes have been explained. In this blog we will talk about “Why” cheatcodes exist at software companies. Also, why the Software industry has more cheatcoders compared to other industries.

Let’s get started.

.

Cheating in another industry

.

Let’s exercise our imaginations. Let us use software industry cheatcodes in some other industries e.g. farming, construction, finance etc.

How about – a farm labourer sends the owner a late night text message. As a farm owner, my first question would be – Can I get some of what you are smoking !

.

Cheatcodes that thrive in the IT industry would be NON starters in many other industries. I hope this is obvious. This brings us to the next question.

Why is the Tech industry a fertile ground for so many cheatcodes ?

I mean really ! Pause reading any further. Take a minute to think about it. Bring in your inputs before you read any further.

.

Nature of the ware

Answer to the above question begins with another question: What do software companies produce ?

I hope you said ‘Software’ !

.

Let’s follow up the answer with yet another question ( looks like a question loop already ! ) :

I hope you weren’t able to answer any of the above questions. Obviously the next question is:

How would we evaluate a software ?

This is the starting point of our discussion.

Wine, a dish, a piece of marble, a car, an egg and other things that exist in the real world. A software exists in the virtual world.

Thus, none of the 5 human senses – touch, smell, see, taste and hear, help us evaluate a software. This puts us at an immediate disadvantage.

Humans are NOT designed to evaluate a software, a software engineer or the work towards building a software.

Software exists in the form of electrons or photons floating inside microprocessors. The microprocessors are inside of computers. Computers might be on the cloud, thousands of miles away. Nature of software (VIRTUAL) puts humans at a disadvantage, for evaluating it.

Most of us might agree to the above idea. But few will “really” understand what’s going on. So, allow me some examples:

.

Ever seen the movie Inception or Matrix ?

The movies depict a virtual world. This world has rules. Few rules were unchangeable, but most were changeable !

Changeable rules were upto the architect/ designer/ planner to be added, changed or removed.

.

.

.

Real world has bound rules and tangible results. Software industry has very few rules and, more importantly, a VIRTUAL END PRODUCT.

.

Software deals with abstract concepts in a virtual world. And because the world is virtual, individuals can design and change almost anything. The cost of investigating a software can be very high. This allows Cheat-coders easy access to claiming East while going West !

.

Cheating is easy in the IT industry. Hopefully this first reason explains why. If not – let’s connect over a coffee …

.

Lots to digest here. Take a walk before we consume more ! Next …

.

Production practices

.

We have looked at the nature of software. Now let’s look at the production “system” itself. i.e. the practices used to develop softwares.

Product companies use manufacturing systems like: assembly lines, supply chains, inventory management etc. Similarly, software companies use systems to produce softwares. These systems are called Production lifecycles. Each system has multiple steps.

Fancy words (Agile, Waterfall etc) can be used to describe each system. Regardless, these are the basic real steps that go into the development of a software.

.

Simplifying the above list for a layman:

.

Enticing enough ?

Humans are designed for audio/ visual cues, and NOT words. This is how evolution designed humans. ( I realize the irony with the length of my blog here 😀 ).

This also means that mostly – my lengthy emails will escape scrutiny. A cheatcode opportunity ! #obscurityByLanguage

.

Also, words are very momentary, fading, fleeting, ephemeral. This is the nature of words. How many conversations from today do you remember “word for word” ?

Exactly my point.

.

I will miss something even when I try my best. I will NOT remember “all” requirements, designs or code for any project. I don’t remember what I ate for breakfast today ! and that applies to any number of times you read this blog. ( by the way I am pretty good at my job )

Sometimes words are documented. Even then, they are easy to be “interpreted” per one’s bias/ convenience.

.

Today’s world has project management softwares like Jira. There was a time when these software did not exist. During those times:

Doing the above is still easy. Just a bit less.

Ring a bell ? Cheatcode opportunity !

.

Software processes being word intensive translates to:

Here is true-ish mail, one of my good colleagues received. Below mail perfectly describes the power of words. Words are used here to hide information, by providing too much data. #obscurityByLanguage

I made changes to hide some identities.

.

Thank you Raj, Rani and the entire team who helped us do this entire exercise onsite, and also the folks involved into debugging at various levels.

We understand that there were some teething issue, of which, the following two were most troubling:

– The numbers were not matching across logins.

– When a person was marked Done, it took a lot of time to mark him/her, as such.

.

We are also aware that there may be issues other than these, but since we have a limited bandwidth, we may not be able to open all chapters in parallel.

However, due attention may be given to them as they are prioritised.

The cause of the second issue was very apparent, and was found to be the Done API call, taking much longer than expected to respond.

This was rectified by disabling the call through a configuration change, and letting the person Done, without settlement.

The count issue is particularly interesting.

We have done several rounds of testing where we have logins in parallel and found that the counts do get updated in all the logins correctly. (these test were of course done on environments other than Prod)

However, when we did the same experiment today on Prod, we found that the count issue (0..200 to 0…200 …) not only happens when we start the website again (first counting has already happened), but also when the website is already running. (we are already on dashboard, or any screen beyond it)

During this, the application manifests the count problem in the form of “Red” to “Yellow” to “Green” to “Red” transition of the indicator at the top right of dashboard (which represents the sync statuses) where,

Red = Trying to Connect (because the connection somehow broke)

Yellow = Syncing (trying to transfer data, after connection was established)

.

Now if both these sync states have started to interleave at regular intervals, it is a sign that the connection has irrecoverably broken, and the login may not be able to send/receive any traffic. If we exit the application at this stage and come back, the app will not get past data prep screen)

We believe this very state is when count mismatch will start to begin.

With each login running the exact same query, there is no reason the results can be different for them.

Of course the counts are different on different logins, but each login is correctly reflecting the count IT has.

To diagnose this issue and also to reflect these sync states better to the end user, we’re thinking (and trying) to make some changes, which will allow a user to better identify when something wrong with sync connection has happened, and the login may no longer be able to reflect the correct count.

Again, this may not be easy, but we will have to figure out why the connection breaks, and may also be our best bet to get the counts right, as the application code neither plays any role in the sync, nor in managing the connection for it. (the library internally does).

Suggestions are welcome.

#obscurityByLanguage should be clear from the above mail. Imagine the cheatcode opportunities, word intensive business practices provide !

There can be ( in fact there always are ) :

.

So – we’ve taken a crunchy cone of a virtual product ( software ) and added a generous scoop of difficult business practices !

Let’s make this more interesting.

Industrial age Org structures

Lets go ahead and add a scoop of “ancient org structures”, to our delicacy !

.

Cheatcoders always have their fair representation at organizations. At the same time, there are always some people interested in good, honest hard work. Among the well intended folks, there are hardly any that are willing to “bell the cat”.

I took help from Game Theory to explain the behaviour. Here is an excerpt from the book “The Art of Strategy”

The problem of collective action is a variant of the prisoners’ dilemma, albeit one with many more than two prisoners. … The problem is, who will risk his life to bell the cat ?

… How can an unpopular tyrant controle large populations for long periods ? Why can a lone bully terrorize a schoolyard ? …

But the communication and coordination required for such action is difficult, and the oppressors, knowing the power of the masses, take special steps to keep it difficult. When people must act individually and hope that the momentum will build up, the question arises “Who is going to be the first ?”. Such a leader will pay a high cost – a broken nose of possibly his life. His reward may be posthumous glory or gratitude. There are people who are moved by considerations of duty or honor, but most find the costs exceed the benefits.

.

Hardly any team member would like to take a cheatcode issue forward to the HR, Managers, Senior leaders etc. The same folks would be comfortable sharing the most bitter, caustic, vitriolic feedback on online platforms like Glassdoor. But NEVER to the folks who could really make a difference. I found this strange.

Many might dismiss the online comments simply as “frustrations”. But, let’s hit pause on being judgemental and hit play on being curious.

.

Using Game Theory, how can one cheatcoder trouble a big team ?

.

I submit – Large to mid sized software orgs are structured taking a leaf from Industrial age factories. Factories delegated down multiple layers of hierarchies. This was to mass produce products. Same goes for Software organizations.

These hierarchies tend to have the following characteristics:

.

To avoid vagueness, let’s take a real life example from a giant Indian IT company:

A team working for a Medical equipment organization had multiple Cheatcode managers.

Engineers bitched around lunch breaks and coffee machines. But, never brought the issues forward. Cheatcoder culture was upto 3 levels up their chain of hierarchy. Critiquing could land them into trouble.

The hierarchy above 3 levels was never visible or accessible..

.

Out of many managers … one was a cheatcode maestro. This was known not only to the engineers, but also to the manager group. Yet, no-one brought the issue forward.

Everyone was clear about the problem. But, they did not have confidence in bringing the issue forward. A pissed off manager with complete control over your performance is the last thing an engineer wants.

.

Later, our disaster artist painted some back to back masterpieces. Some very important projects went to dump. He was moved to another team.

Note – he was still NOT fired, which would have been the logical thing to do.

His friends helped him avoid trouble during the bad times. Most engineers will get discouraged from reporting cheatcode issues, seeing such a spectacle.

.

Cheatcoders survive/ thrive at industrially hierarchied software organizations. Any surprises ?

.

Invisible Ships

.

Ever heard of: Ships not seen or Invisible Ships phenomenon?

The story goes like – when the first Europeans arrived at the different coasts viz. Australia, South America, Cuba etc, the natives completely ignored them. Only once the sailors landed on the shores, did the natives actually ‘see’ the sailors and the ships.

The common theory is – the concept/ idea of a ship was so alien to the native worldview, that their minds couldn’t interpret the visual. Their minds did not see the possibility …

Floating water body == Possible other people == Possible danger

.

Essentially they failed to ‘see’ the ships. Only after the idea of ‘Ship’ was absorbed in their minds, the natives were able to ‘see’ the ships.

.

My theory is that something similar happens with Cheatcodes. Ignorance of what cheating might ‘look like’ provides growth conditions for cheating.

So, if I were a senior manager, and you said to me: “But he just forwarded the email to me !”

And I was like: “And?”

Then, I lack the understanding that the person being discussed – conducted himself like a postman! He did NOT add value to the task and probably abdicated his responsibilities.

I failed to ‘see’ the ship. Many times, cheatcoders will come ashore, invade the organization, kick out the good people and take over the land!

.

A poor Hindi analogy would be “Kue ka Mendhak”, which literally translates to “The well’s frog”.

The frog believes the well to be the whole world and lacks exposure to what lies outside the well.

.

The lack of knowledge about what is a Cheatcode, helps the cheatcode !

Now, ask yourself… Do you see?

.

In conclusion

.

We looked at reasons – software industry provides space to cheatcoders. The reasons are few in number. But each has a big impact on enhancing the cheatcode landscape.

Some causes were part of the nature of the industry i.e. the virtual nature of Software, while others were man-made (so to speak) – industrial practices, org hierarchies etc, yet others were due to the lack of understanding of the issue.

.

As we can imagine cheatcodes create problems for both – Individuals and Organizations. We discuss these in the next blog.

 

.