Mental Model- Death By A Thousand Cuts
Are you aware of this concept of ‘death by a thousand cuts’? For me it means somewhere between the two wiki entries related to it. One is about a torture technique. The other is from psychology.*
The meaning that’s remained with the most about this topic is the one that came up during a discussion with my earlier manager. And I have sort of adapted that phrase for the mental model which describes that particular meaning. The discussion was probably about agile or complex application architecture. My manager hated both. For me, I think sometimes the complexity- like entropy- in applications grows unless deliberate work is done to reduce it. And agile- particularly SAFe- was one of the worst things to happen to a couple of projects where it was followed. Anyway back to the topic. My manager explained it thus- you don’t die by a single blow or large cut in the war; you die by having to endure small cuts over a long period. Similarly, applications, platforms don’t become useless just because of this feature or that shortcoming. It is a little bit of this and a little bit of that.
Think about this. You don’t burden the camel at once. And then all of a sudden the last straw does the trick. Have you ever given up on something because over a period, you just ended up giving up on it? Most likely that was a death by a thousand cuts.
I know only a few instances when people left their jobs for something great. Mostly they left their jobs to get away from something which was just too much to take. Have you encountered SBI aunties, college professors, friends where you reached a point- not at once- but with accumulated stress over a period of time when you snapped. It probably went against your nature. But you can stretch the rubber only so far. I think this accumulated thing is not good.** It can take a some unpredictable ways out. The harmful thing that does not kill you makes you weaker.
We should avoid things like that if we can.
As an engineer you can- sometimes- see that the complexity of the application is increasing. At other times you have to be a little away from the system to look at it analytically. Then after a while people start talking about migration to different stack, off the shelf product, managed service, rebuilding/ separating a couple of stand alone modules, merging similar flows from different applications so as to ‘rationalize’ them. Work needs to be done to reduce the complexity. But mostly reducing the complexity may not even be possible due to financial, timeline constraints.
Aside: Nobody wants to change ‘something that is working’. It’s not practical. Why disrupt something that is working fine?*** One of the reasons a couple of friends I respect did not want to be in a manger position was that- they did not want to be into a role which they did not like others in. For example, the same manager who told me about the ‘death by a thousand cuts’ went to a large Indonesian techie company as engineering head and then had to ‘rationalize’ the tech stack- only java, mysql, python, kafka, spark are permitted. And he said, he had joined that company specifically because they worked on Go, Riak, Arrow, and things like that; and now he’s the one who had to make these rationalizations. While it is required as a part of the job, he did not seem to like it. A couple of my friends do not like to be in such positions.
*It seems there is a Taylor Swift song of that name; which I found out about just now when googling for links.
**It reminds me of a nice description about Scarlett’s behavior from Gone With The Wind. But this is not the place for that.
*** Probably I should refrain from posting links to pages of people. I have done that in the past for V Vaughan’s post. But maybe I shouldn’t. Otherwise, they may end up blocking me on linked in. That may be the last straw for my LI usage such as it is.