I believe this is the source of so much complexity, faultiness and stress caused by absolute majority of IT systems out there.

One of the most ubiquitous cognitive biases in IT is Mental Shotgun🡕.

In a nutshell, when we are facing a complex problem, our mediocre brain plays this trick on itself:

It substitutes the difficult question it cannot understand with a simple, broad, familiar question it is comfortable with. Intuitively it feels that the original complex question will be answered somewhere in the broadness of a familiar, simple question. This lets our brains pretend that an answer to a simple substitute question actually answers the original difficult one.

The mental shotgun makes it easy to generate quick answers to difficult questions without imposing much hard work on your lazy System 2 Daniel Kahneman🡕

Since this IT racket of ours is fairly complex, the prevalence of this bias is understandable. It also makes it a bias to watch for. I initially planned this post as an illustrative list with some interesting examples of Mental Shotgun from our pop culture driven industry.

With prominent candidates as:

The Data Lake
From:"How to effectively use available information?"
To:"How to store as much data as we can?"

Or

Continuous Pushivery
From:"How to discover unknown unknowns fast?"
To:"How many times did I push code?"

But, when untangling substitute questions a common corporate developer or manager is simplifying their lives with, like:

I did a SOLID
From:"What is the simplest code that achieves the goal?"
To:"Is my code clean?"

Or

I did a SCRUM
From:"Are we moving towards the goal?"
To:"Are we doing agile?"

I realized those questions are not even intuitively related to the questions that can solve the actual problem. It is a substitution of the problem itself. I cannot write it off to our fallible brains and biases. It is their playground of self indulgence with “best practices” and “agile processes”. They are playing with themselves.

While there’s nothing new here for most of you: 90% of “tribes/squads/chapters” in corporate IT is just that. Majority of startups are no different. It is an interesting picture to explore though: the mental gymnastics and psychology of IT Playground nerds and agile practitioners. After 17 years in this racket I have some understandings to share.

It is also a problem that needs to be stated. The emperor is not only naked, he is pushing his taint into our faces as a blessing.

The scene of Playground IT

Playground IT systems are not created for users. Users are treated as a nuisance: they change their minds and mess up the clean code that a Playground dev already imagineared with himself.

The playground is vigorously guarded from users by business analysts and “shit umbrella” managers. The goal here is to make said shit flow in the opposite direction: the toy solution created in Playground IT is pushed onto users as a clean gift from playground nerds that know better.

How about that for “Inversion of Control”? Here’s the kicker: the excuses for Playground IT practices are stated as if they are making the IT system better - more testable, with better architecture and maintainable.

The toy solution Playground IT produces is exactly the opposite. It cannot be simple because Playground IT does not care about its fitness. It is anemic to actual needs of the user and full of contrived complexity of nerds’ toys. Playground IT can only produce stressful to use, unreliable and sluggish systems.

Inside Playground IT

Part I - Managers’ Dollhouse

The fault in this incredibly wasteful self indulgence lays 100% with management. It is because management creates playgrounds with their minds. Playgrounds then self-select for “manageable” devs. Manageable devs like playgrounds because it makes for a safe space to play with themselves.

Absolute majority of managers out there are grossly, sadly but understandably incompetent in IT. And management for that matter… I will let you in on a little secret here: those people are not deep thinkers. They are manageable go-getters. Go-getters that simplisti’fy problems for higher-ups. That’s why they got selected.

The reason our go-getter manager cannot trust this responsibility to more qualified people than him is because he is a company man. He wants recognition of higher-ups for his achievement. But more fundamentally, he is not in a business of trust, he is in a business of control. He needs manageable people, a.k.a Human Resources. Manageable people are accountable to the manager. Accountable people are not responsible for the achievement. Manager is.

Dollhouse mangers’ purpose is recognition from higher-ups.

Creating IT systems from pure thought-stuff🡕 is a weird and foreign problem for our simplisti’fier. It requires creative and most importantly responsible people. Simply because software development is a discovery process with lots of unknown unknowns. It is comprised of gazillions of unexpected details and you need people to offer responsibility to take care of them.

Such people are too difficult to reasonably simplisti’fy for our go-getter manager. They are very, very foreign to the system he is in. They ask uncomfortable, weird, complex questions. Complete opposite of what he wants. He wants somebody in his likeness - a simplisti’fier that talks his language. Language of controllable, presentable, stream of “progress”.

Luckily, our pop culture driven industry has him covered. Plethora of agile SAFE practitioners to chose from. A more sophisticated simplisti’fier will go for scrum-ban facilitator “non master”. Dev-ops practices will push devs to push features. They will deliver and deliver and deliver - continuously.

How our industry is overrun by sold-out, loud-mouth guru “recommended practice” sellers is a post for the future. The point here is: recommended practices are an easy sell to our simplisti’fier. He’s been sold on a promise: just following the practise is progress. Easy progress to control, measure and show to our go-getters’ higher-ups.

Progress Squad

Having a team of subordinates is a rite of passage for our company-man manager. The first thing he does is find a safe, manageable right hand that will assemble a “competence pool” for him. Lets call him facilitator Frank. In IT, a CTO or Tech/Team lead often fulfills that role. Frank is an avid practitioner of recommended practices. He will assemble a “squad” ready for measurable, presentable achievements.

This is where managers’ Dollhouse gets created. The recommended practice ninja selected by our manager needs to safely apply his SAFE on people he selects too. Frank filters for people that take his toys seriously. He will make a space for good devs to practice good recommended practices. Frank will select good ones. Good ones appreciate him for being understanding, enabling, protective facilitator.

Managers’ Dollhouse is selecting for devs that like to giveaway responsibility to the processes, rules, and practices.

This is a game🡕 that Frank and devs are playing. Frank enabled this. But more importantly, he is also so required here to “facilitate” between “business” and devs. Frank, being a simple guy that he is, naturally and subconsciously created a playground for himself at the request of our simplisti’fier.

Dollhouse Symptoms

Dollhouses are easy to spot because they are self protective. Filtering for manageability starts at the gate. Competent, responsible people do not qualify for managers’ Dollhouse. A generic, detached “Talent Acquisition Partner” or HR functionary is just the role for that. She will test you for obedience, conformance and safety. Safe will pass.

Generic, expendable, fungible people from “competence pools” will be accepted into prepared playgrounds well encapsulated from the rest of the system. The bigger the pool the safer the “talent”.

Creativity is also a very foreign and suspicious trait, but a necessary evil for market competitiveness. It will be simplisti’fied into a “R&D” department where nerds will play with newest toys in their well encapsulated and insulated playground.

Since our go-getters’ purpose is recognition, he often creates a toy purpose for him to achieve. In corporate IT, toy purpose for managers’ Dollhouse is often called an “initiative”. Startups are of course “making the world a better place through distributed crypto protocols”.

Even if the meaningful purpose is actually stated somewhere, the simplistifi’cation to achieve it through recommended practices will create a dollhouse that has it’s own purposes. Managers’ Dollhouse creates detachment from actual purpose and substitutes it with tasks. Tasks that are measurable and, most importantly for him, presentable as progress. It should be clear now why scrum is the most popular “agile practice”.

This detachment from use and purpose makes for a great safe space for manageable devs to play with themselves.

Part II - Nerds’ Playground

The really interesting understanding here is mental gymnastics through which a Playground dev gives meaning to what he does. Solving an actual problem is not it. Most likely you’ll get annoyed looks if you start asking about the purpose and questioning whether the system he is working on is actually achieving it.

But he has to somehow connect his efforts with the purpose in the real world, right? Not really. Those real people annoys Playground dev. He doesn’t like them. What such dev does is more like finding validation/excuse to push his toys onto users or other devs.

One of more prominent righteous excuses to push is “clean code”. I did a SOLID, I did a TDD, I did a microservice - my code is clean. What are they cleansing themselves of?

“Developers’ Neurosis” is a major driver here: messy realities of users are threatening my clean code in my playground. Through cleansing rituals of TDD, BDD, SOLID, etc… I remain a clean developer and guard my clean code.

For a Playground dev, the purpose is in pushing his cleansing toys implemented with his clean code onto the dirty world through features.

Another typical symptom is obsession with classes and types. A nerd is conforming messy users to his playgrounds’ “correct” view. What doesn’t comply to it is “incorrect” and is rejected from his clean playground.

Complete self absorption, not a hint of care for the user. The result is all too familiar to all of us. Playground devs’ vocabulary is forced into our day-to-day through features like: “buy QR code”* or “chat with a bot”**. We are forced to use simplistic, buggy programming languages he created in his likeness, as a “logical” and clean gift for us.

To schedule an appointment to a doctor, you are presented with a form to enter a bunch of predicates for time, location, a type of doctor you want to see, etc… You are creating a query to filter a database. You know why? Because Playground dev is working with a database and is writing queries for it.

SPA didn’t work but SOLID came out…


Further reading:

[Add comment]
comments
  1. by on 04 Mar, 2023
    I think there is an additional reason here too. Software development work is (too often) seen as heads-down, anti-social work. Large corporations often bridge communication between software developers and the business/end-users via third-parties, such as product owners/manager, architects, and business analysts. Remember the "telephone" game we all played in kindergarten, where a message whispered between participants becomes comically unrecognizable by the time it reaches the last person? That is BigCorp software development in a nutshell.

    Solving this communication problem is uncomfortable. Connecting software developers with end-users is hard. It means software developers have to have courage to ask "dumb questions" when the end-users explains something too quickly in jargon-laden terms. It means that end-users have to be patient, with the time to teach and explain enough about the problem domain. People with strong communication *and* technical skills are hard to find, and creating ongoing mutual respect and cooperation between end-users and the oft-hated IT department is only possible when employee attrition is low enough to create long-standing relationships.

    Software development is fun when it is a high-momentum, self-contained exercise. So we direct our energy to complexity, because its fun and safe. We don't need to stop and engage with end-users who speak a language we barely understand. We don't need to create consensus among disagreeing end-users representatives. We just need put on some good music, drink some coffee, and solve clean technical problems, rather than messy people problems. I'd guess most software developers would say "you don't pay me enough to deal with people", and walk away.

  2. by on 04 Mar, 2023
    Hi yold_. I think software development is made heads-down, anti-social work by simple-minded managers. They create an infantilized environment that self-selects for devs that don't like to talk to people.

    Talking to people is trusted to "big boys" from business. You've listed the roles. Business big boys will sell complexity to clients through IT woo wooo. More complexity - more revenue.

    It is by design. It didn't "just" happen. Corporations breed infantilized devs and make it a norm. This proliferates an understanding of a dev as a nerd who plays with his toys.

  3. by on 04 Mar, 2023
    Looking at human nature - the psychology of it - in these highly technical environments is very refreshing. It has to be faced sooner or later, I say. Further recommended reading material (which I read and loved) - Will Stor's "The Status Game".
    Dollhouse mangers’ purpose is recognition from higher-ups.
    Yup, that's "The Status Game" right there.

    Several types of status game are played:

    • "Virtue" Status Games (conforming to a framework, no matter how ill-fitting to the real world)
    • "Prestige" status games - designing an elegant system, and being respected for the elegance and cleverness
    • "Dominance" status games - for HR and management types, who control and unnecessarily oppress everything, striking fear into employees to conform.