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:
| From: | "How to effectively use available information?" |
| To: | "How to store as much data as we can?" |
Or
| 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:
| From: | "What is the simplest code that achieves the goal?" |
| To: | "Is my code clean?" |
Or
| 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.
- What does it mean: “the system is testable” if the system is barely vaguely arguably useful? It means “I did a TDD”.
- What does it mean: “the system is well designed” if the purpose of the system is not distilled? It means “I did a microservice”.
- What does it mean: “the code is maintainable” if the code does not talk about users’ needs? It means “I did a clean code”.
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.
- Sebastian did a TDD, test coverage is 94% now. Sebastian doesn’t want to talk to “business”.
- Andrew is refactoring to React State Functions. He is grumbling about technical debt that his manager is “not allowing” to be taken care of.
- Navi from testing department is doing BDD. Navi is not answering emails.
- Peter did a pair programming with junior Jimmy. Now Jimmy knows the difference betwen a mock and a stub. He will mock “User” object soon.
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.
- I implemented a “high priority” feature required from me by scrum master who talks to “business”.
- I chose the correct recommended practices to follow - therefore the result is good.
- I used the correct new framework everybody is using - therefore the result is good.
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 announced “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:
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.
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.
Several types of status game are played: