5 ms·

While the text touches on many points I would immediately sign, the paragraph starting with "Because engineers are human beings who often form an emotional atta

While the text touches on many points I would immediately sign, the paragraph starting with "Because engineers are human beings who often form an emotional attachment to their creations, ..." is really out of place. The cause of complexity is not emotional attachment, these are decisions being made. The decision to add feature after feature and punt on maintenance for example is something that has little to do with emotions. There is a lot of agency that engineers, SWE and SRE alike have in shaping how things are. However there can be good reasons to abandon simplicity. The real trouble here is not psychology but that as a profession we are really bad at measuring and estimating the effective cost of maintenance. Part of that is considering measures to improve simplicity and maintainability as cost that comes without gain and somehow less important than features, and then just accept giant rewrite a few years later. A continuous portion of upkeep would likely be more economical and real engineering has always included an aspect of economy - cost vs benefit. IMHO the loaded accusation of emotional attachment might be rooted in an "us vs them" attitude (SRE vs software engineering) that should have no place in a sober discussion on the value of simplicity and it diminishes an otherwise great text.

CraigJPerry 2y ago
>> Because engineers are human beings who often form an emotional attachment to their creations, confrontations over large-scale purges of the source tree are not uncommon. Some might protest, "What if we need that code later?" > the paragraph starting with "Because engineers are human beings who often form an emotional attachment to their creations, ..." is really out of place. FWIW I’ve definitely encountered developers clinging to things when the business context has completely changed. I totally recognise the scenario in the original text.
- burakemir 2y ago
  Sure, but if we argue that these values and principles should be applicable, then it should also be possible to make an argument why and not blame the irrationality on emotions. It seems more likely that bounded rationality is at play here, where different parties only know part of the picture (and fail to bring these together and find out what would be best globally.)
  - philosopher1234 2y ago
    I don’t follow why we shouldn’t blame the irrationality on emotions. Emotions are massively important, and people do irrational things because of them all the time. Why pretend that’s not true?
    - burakemir 2y ago
      The question is not whether emotions can cause people to be irrational. They can! Not every case of irrational behavior is caused by emotions though. And when we are making an argument that people are acting against their own interests, it may help to ponder what makes them do so. All the more when we are claiming principles and values that should be accepted by everyone. "If you don't believe me you are acting irrational / it's because you are emotionally attached" does not seem to be an attitude that gets closer to real causes in a discussion on how to best seek simplicity, but rather a recipe for avoiding discussion or a "thought-terminating cliche." There must be a better argument for convincing people to let go of code / clean up etc.
      - philosopher1234 2y ago
        But, if it is the truth, then it seems to me like it does get us closer to the truth. I don’t think irrational means there is no explanation for the behavior, it’s closer to saying that the behavior is not in anyone’s best interests, it’s not thought through. Clinging to code you wrote is a very natural thing to do, there are many reasons we do it, and most of the time it’s irrational.
    - kortilla 2y ago
      You’re assuming the conclusion. What may appear to be irrational emotional behavior can be completely rational under a different set of information.
    - deleted 2y ago
      [deleted]
    - chambers 2y ago
      Fear, I think. It's unpleasant to know someone is harming the common good because they're being selfish. Some people can handle that knowledge and admit "well someone clearly owed their promotion to a legacy module/abandoned code/unused system". Whereas others are that someone or are afraid of that someone, and they make up a bunch of excuses. This dynamic comes up often in engineering management.
arccy 2y ago
But people do get attached to their creations, they don't want their things deprecated/removed, since to them it may feel like their thing is thrown away or wasted work down the drain. While they may not obviously state it as such, it can be the underlying reason driving their arguments (e.g. sunk cost fallacy).
- burakemir 2y ago
  Maybe this is also about the desire to create, which of course is also common in engineering. It does not contradict my argument that the cost of maintenance and operations is being ignored eg when one creates things all the time and never removes stuff. And it should be possible to measure or estimate that cost.
jimmySixDOF 2y ago
When containers got going there was a phrase used in devops to think of servers as "cattle not pets" for just this reason.
- XorNot 2y ago
  I never took that as dealing with emotional attachment, it was just a shorthand to express that at any moment you would kill cattle so don't do things you can't easily replicate.
- kortilla 2y ago
  No, that had nothing to do with emotional attachment. It’s a short phrase to remind people that they can’t make each device special with one-off because it needs to be repeated/destroyed all of the time. Separately, cattle vs pets is much older than containers. It got popular with ephemeral EC2 instances when people were first forced to grapple with lifetimes of VMs measured in hours and the ability to scale massively as needed.
  - wlonkly 2y ago
    A little of both, I think. I remember having decommissioning ceremonies for long-lived, specifically-named servers, and I remember the era when people were proud of astoundingly long uptimes. Both of those things are aspects of pet-hood that treating servers like cattle changed.
scott_w 2y ago
I think the examples the paragraph gives more than backs up the statement. I’ve met people who comment out code instead of deleting it (luckily not in a long time!) and I feel the authors speak from experience here.
- burakemir 2y ago
  Curious what examples do you see there. I don't doubt the experience. When I draw analogies of my past experiences to present situations, that does not mean that my past experiences are the best way to convince people of what is the right thing to do. I still need to do the hard work of pointing out what it is that is in the common interest and why eg deleting stuff and simplifying is good. In such a discussion it won't help me to say people who disagree with me are generally just emotional, does it? Even if I may have encountered people with such emotional reactions.
  - scott_w 2y ago
    > Curious what examples do you see there. I don't doubt the experience. I’m not going to just copy and paste the article for you. It’s literally right there.
intelVISA 2y ago
> Because engineers are human beings who often form an emotional attachment to their creations Because engineers are human beings who often form an emotional attachment to their job security It's understandably very unwise to admit that Very Complex Solution that cost A Lot Of Money was A Bad Thing
- ozim 2y ago
  Unfortunately complex solution we have accumulated over time is usually because business did not want to spend a bit more up front to come up with cleaner solution. In the same way business is also very reluctant to spend time/money on cleaning up stuff. I never ever had to make up complex stuff on my own. It always happens on its own.
probably_jesus 2y ago
[dead]
mrbungie 2y ago
I think that is being transparent with what actually happens in the real world (engineers, at least in part, being human and emotional in their decisions), rather than just talking about impossible ideals (engineers thinking about tradeoffs in a purely objective matter). NIH, CV based development, preference for shiny/new things and a myriad of other "engineer/organizational diseases" exist, you know. And there are even SaaS/PaaS/XaaS marketing teams exploiting such human qualities when making software sales.
oooyay 2y ago
I'm a SRE and I disagree too, though, I think you're giving SREs too much credit in the category of our hegemony for an "us vs them" debate. Maybe at Google SWEs having relationships with their code based is a well studied thing. It could also just be someone's opinion that managed it's way unchallenged into the book. That's to say, Google SRE wasn't the best or last iteration of SRE. I personally think systems evolve the way you describe because of a system of incentives. There are more incentives for features than there exist for refactor and non top priority defect fixes. This comes from the people who hold power to shape incentives and they often do so with conflicting priorities and superficial understandings of the existing incentive structure. I'd also like to say that it's my own personal theory that systemic issues can only be caused by systemic forces. Individual mindsets cannot be to blame then; if a mindset has become systemic (example: SWEs overly attached to code and features) then your next question should be "why?". There's a system that enforces that, and if you don't look beyond personal obsession then you'll never find it.
- burakemir 2y ago
  I like this way of saying it. I don't think anything here is well studied at all. It is not like we are all fishing in the dark but the organizational structures that determine the conditions in which software development and operations happen are not well understood. I found Herb Simon's writings and his concept of bounded rationality very lucid. When we shift from "reliability" to "safety" we also need to shift from the individual to the system.
jimbokun 2y ago
It’s not specific to software engineers. People in every field get emotionally attached to their own creations.

CraigJPerry 2y ago

>> Because engineers are human beings who often form an emotional attachment to their creations, confrontations over large-scale purges of the source tree are not uncommon. Some might protest, "What if we need that code later?" > the paragraph starting with "Because engineers are human beings who often form an emotional attachment to their creations, ..." is really out of place. FWIW I’ve definitely encountered developers clinging to things when the business context has completely changed. I totally recognise the scenario in the original text.

burakemir 2y ago
Sure, but if we argue that these values and principles should be applicable, then it should also be possible to make an argument why and not blame the irrationality on emotions. It seems more likely that bounded rationality is at play here, where different parties only know part of the picture (and fail to bring these together and find out what would be best globally.)
- philosopher1234 2y ago
  I don’t follow why we shouldn’t blame the irrationality on emotions. Emotions are massively important, and people do irrational things because of them all the time. Why pretend that’s not true?
  - burakemir 2y ago
    The question is not whether emotions can cause people to be irrational. They can! Not every case of irrational behavior is caused by emotions though. And when we are making an argument that people are acting against their own interests, it may help to ponder what makes them do so. All the more when we are claiming principles and values that should be accepted by everyone. "If you don't believe me you are acting irrational / it's because you are emotionally attached" does not seem to be an attitude that gets closer to real causes in a discussion on how to best seek simplicity, but rather a recipe for avoiding discussion or a "thought-terminating cliche." There must be a better argument for convincing people to let go of code / clean up etc.
    - philosopher1234 2y ago
      But, if it is the truth, then it seems to me like it does get us closer to the truth. I don’t think irrational means there is no explanation for the behavior, it’s closer to saying that the behavior is not in anyone’s best interests, it’s not thought through. Clinging to code you wrote is a very natural thing to do, there are many reasons we do it, and most of the time it’s irrational.
  - kortilla 2y ago
    You’re assuming the conclusion. What may appear to be irrational emotional behavior can be completely rational under a different set of information.
  - deleted 2y ago
    [deleted]
  - chambers 2y ago
    Fear, I think. It's unpleasant to know someone is harming the common good because they're being selfish. Some people can handle that knowledge and admit "well someone clearly owed their promotion to a legacy module/abandoned code/unused system". Whereas others are that someone or are afraid of that someone, and they make up a bunch of excuses. This dynamic comes up often in engineering management.

arccy 2y ago

But people do get attached to their creations, they don't want their things deprecated/removed, since to them it may feel like their thing is thrown away or wasted work down the drain. While they may not obviously state it as such, it can be the underlying reason driving their arguments (e.g. sunk cost fallacy).

burakemir 2y ago
Maybe this is also about the desire to create, which of course is also common in engineering. It does not contradict my argument that the cost of maintenance and operations is being ignored eg when one creates things all the time and never removes stuff. And it should be possible to measure or estimate that cost.

jimmySixDOF 2y ago

When containers got going there was a phrase used in devops to think of servers as "cattle not pets" for just this reason.

XorNot 2y ago
I never took that as dealing with emotional attachment, it was just a shorthand to express that at any moment you would kill cattle so don't do things you can't easily replicate.
kortilla 2y ago
No, that had nothing to do with emotional attachment. It’s a short phrase to remind people that they can’t make each device special with one-off because it needs to be repeated/destroyed all of the time. Separately, cattle vs pets is much older than containers. It got popular with ephemeral EC2 instances when people were first forced to grapple with lifetimes of VMs measured in hours and the ability to scale massively as needed.
- wlonkly 2y ago
  A little of both, I think. I remember having decommissioning ceremonies for long-lived, specifically-named servers, and I remember the era when people were proud of astoundingly long uptimes. Both of those things are aspects of pet-hood that treating servers like cattle changed.

scott_w 2y ago

I think the examples the paragraph gives more than backs up the statement. I’ve met people who comment out code instead of deleting it (luckily not in a long time!) and I feel the authors speak from experience here.

burakemir 2y ago
Curious what examples do you see there. I don't doubt the experience. When I draw analogies of my past experiences to present situations, that does not mean that my past experiences are the best way to convince people of what is the right thing to do. I still need to do the hard work of pointing out what it is that is in the common interest and why eg deleting stuff and simplifying is good. In such a discussion it won't help me to say people who disagree with me are generally just emotional, does it? Even if I may have encountered people with such emotional reactions.
- scott_w 2y ago
  > Curious what examples do you see there. I don't doubt the experience. I’m not going to just copy and paste the article for you. It’s literally right there.

intelVISA 2y ago

> Because engineers are human beings who often form an emotional attachment to their creations Because engineers are human beings who often form an emotional attachment to their job security It's understandably very unwise to admit that Very Complex Solution that cost A Lot Of Money was A Bad Thing

ozim 2y ago
Unfortunately complex solution we have accumulated over time is usually because business did not want to spend a bit more up front to come up with cleaner solution. In the same way business is also very reluctant to spend time/money on cleaning up stuff. I never ever had to make up complex stuff on my own. It always happens on its own.

probably_jesus 2y ago

[dead]

mrbungie 2y ago

I think that is being transparent with what actually happens in the real world (engineers, at least in part, being human and emotional in their decisions), rather than just talking about impossible ideals (engineers thinking about tradeoffs in a purely objective matter). NIH, CV based development, preference for shiny/new things and a myriad of other "engineer/organizational diseases" exist, you know. And there are even SaaS/PaaS/XaaS marketing teams exploiting such human qualities when making software sales.

oooyay 2y ago

I'm a SRE and I disagree too, though, I think you're giving SREs too much credit in the category of our hegemony for an "us vs them" debate. Maybe at Google SWEs having relationships with their code based is a well studied thing. It could also just be someone's opinion that managed it's way unchallenged into the book. That's to say, Google SRE wasn't the best or last iteration of SRE. I personally think systems evolve the way you describe because of a system of incentives. There are more incentives for features than there exist for refactor and non top priority defect fixes. This comes from the people who hold power to shape incentives and they often do so with conflicting priorities and superficial understandings of the existing incentive structure. I'd also like to say that it's my own personal theory that systemic issues can only be caused by systemic forces. Individual mindsets cannot be to blame then; if a mindset has become systemic (example: SWEs overly attached to code and features) then your next question should be "why?". There's a system that enforces that, and if you don't look beyond personal obsession then you'll never find it.

burakemir 2y ago
I like this way of saying it. I don't think anything here is well studied at all. It is not like we are all fishing in the dark but the organizational structures that determine the conditions in which software development and operations happen are not well understood. I found Herb Simon's writings and his concept of bounded rationality very lucid. When we shift from "reliability" to "safety" we also need to shift from the individual to the system.

jimbokun 2y ago

It’s not specific to software engineers. People in every field get emotionally attached to their own creations.