[HN Gopher] How do interruptions impact different software engin...
___________________________________________________________________
How do interruptions impact different software engineering
activities
Author : kiyanwang
Score : 179 points
Date : 2025-01-19 22:56 UTC (1 days ago)
(HTM) web link (rdel.substack.com)
(TXT) w3m dump (rdel.substack.com)
| yodon wrote:
| 40 or so years later, the book Peopleware by DeMarco and Lister
| remains the best quantitative study on environmental impacts on
| developer productivity.
|
| The world has changed significantly since it was written, so you
| have to translate their measurements to modern contexts, but it's
| easier to translate real data on human behavior than to guess
| based on guesses.
| froh wrote:
| the OP is a journalistic summary of
|
| Breaking the Flow: A Study of Interruptions During Software
| Engineering Activities
|
| Yimeng Ma, Yu Huang, Kevin Leach
|
| (2024) icsi Portugal
|
| it's not properly quoted, but it's directly linked,
| prominently.
|
| yes, I agree, peopleware is on the must have reading list, but
| this article certainly is not guesses on guesses
| NomDePlum wrote:
| Peopleware is indeed still very relevant. Always felt Slack by
| DeMarco made important points around efficiency seeking
| damaging actual effectiveness, which I always found very
| convincing and chimed with my own experience.
| black_13 wrote:
| Agile is number one interuption of all enginnering activity .
| wink wrote:
| Not sure if this is supposed to be sarcasm, but only from the
| direction of "lock the developers in a room and look what
| surfaces after half a year".
|
| Picking what to work on for [time] without external additions
| is a pretty good improvement over getting new assignments
| daily.
|
| Or maybe you're just doing it wrong, I'm not here to defend
| anything codified in Agile, I'm just saying that elements of
| what most people call scrum has been the best I've seen in over
| 20 years. Maybe I just missed the days of locking yourself in
| your single office.
| p_l wrote:
| I suspect it's more about the way many people experience
| "scrum".
|
| The basic building blocks can actually work great, it's often
| how they are executed and how many places go very much
| micromanagement wrapped in agile's skin while also
| instituting lots and lots of meetings - total opposite of
| what both Agile and XP advocated.
|
| Some of the best agile/scrum I ever worked under came from
| "Scrum master" who explicitly stated that one of his jobs was
| to see what approaches work and change what doesn't work for
| the team.
| exe34 wrote:
| > see what approaches work and change what doesn't work for
| the team.
|
| unfortunately from my experience, "what works" can vary
| wildly from person to person. One person wants to be given
| a task and left alone to understand it and write some
| throwaway code as part of the understanding process.
| another person wants to bikeshed it to death first before
| letting you touch any code. so the first person has to hide
| the work on the prototype and pretend to come up with the
| insights for the first time during the bikeshedding
| session.
| p_l wrote:
| Which is why their job was to figure out a model for the
| team. This specific team.
|
| Sometimes you can compromise, sometimes you can figure a
| proper allocation of resources, sometimes you can part
| amicably instead of murderously.
| pydry wrote:
| Scrum is a bit too proscriptive to allow for that. One of
| the things that "works" is killing sprints, for instance,
| but scrum isn't scrum without a sprint.
| TeMPOraL wrote:
| > _" Scrum master" who explicitly stated that one of his
| jobs was to see what approaches work and change what
| doesn't work for the team._
|
| Ironically, if I were to give one-sentence summary of what
| the idea behind Agile is, it would be exactly that: "see
| what approaches work and change what doesn't work for the
| team". Running through that feedback loop rapidly is the
| _whole point_ of Agile, and the one thing that actually
| distinguishes it from typical management methods at the
| time (as opposed to silly comparisons with "waterfall"
| boogeyman that never even existed).
|
| Everything else is process - the thing that's supposed to
| be sculpted. Focusing on that is committing the sin
| explicitly called out in the Manifesto - putting process
| over people.
| nottorp wrote:
| > of what most people call scrum has been the best I've seen
| in over 20 years
|
| If you're phrasing it like that I've been doing agile since
| way before anyone invented the term.
|
| But that's only 10% of cult agile, which is what is practiced
| generally.
| pydry wrote:
| Agile seems to be used to refer both to a form of cult and a
| form of software development interchangeably and I think it's
| too late to fix that.
| AdamN wrote:
| I've found that agile works if velocity is static and used for
| estimates ONLY and is flat over time. Once velocity is measured
| as an output metric and there is an attempt to improve it,
| you've just left agile and are now in a morass.
|
| In the end, very simple Kanban is the way to go if your org can
| handle it.
| smitelli wrote:
| It's worth pointing out that the "Agile" philosophy is
| literally 4-5 lines long:
|
| > Individuals and interactions over processes and tools
|
| > Working software over comprehensive documentation
|
| > Customer collaboration over contract negotiation
|
| > Responding to change over following a plan
|
| > That is, while there is value in the items on the right, we
| value the items on the left more.
|
| The thing I think everyone has grown to universally despise is
| the cargo cult of "Scrum" that got bolted onto that.
| marcosdumay wrote:
| It's not Scrum. Scrum wasn't even the first. (I think it was
| XP.)
|
| The problem is all the "Agile methodologies". Every single
| one.
|
| (Also, notice that "Agile methodology" as an idea is already
| against the first principle there.)
| SoftTalker wrote:
| Yes. As soon as you're conducting ritual ceremonies such as
| daily standups, you're no longer agile.
| nyrikki wrote:
| It is the pseudoscience of Taylorism and 'Scientific
| management', not the manifesto, which is really just a
| repackaged form of modern organization theory.
|
| The DOD agile BS PDF covers most of it.
|
| https://media.defense.gov/2018/oct/09/2002049591/-1/-1/0/di
| b...
|
| Once the consultant forms start to monetize the GAO's agile
| assessment guide things should get better IMHO.
|
| Unless that gets co-oped somehow, which is possible.
|
| How GM screwed up on the NUMMI plant shows how it is a
| Taylorism problem if you want something outside of tech.
|
| But even TOGAF and ITIL are adjusting because the feds will
| require it.
|
| Taylor measured people loading pig iron into train cars,
| faked a lot of things and the BCG/McKinsey types packaged
| and solid it.
|
| It has always been BS, is part of why the US manufacturing
| sector failed as well as why the USSR failed.
|
| Pretty hard to kill but it needs to die.
| pydry wrote:
| The problem is that those are a really vague and metaphorical
| 4-5 lines so it's hard to argue against somebody projecting
| whatever the hell meaning they want on to it.
|
| I'd argue that "agile" where I have done it and it worked
| well is at its core about tightening up OODA loops - with
| code (refactoring+tests+iterative improvements), with
| customer interaction (frequent interaction/experiment driven
| tests), with team organization (retros, adapting team
| processes).
|
| Feedback loops are, however, not mentioned once in the
| philosophy and neither are any concrete examples of "agile"
| or "not agile".
|
| Agile as a concept will stop being broken when people stop
| saying "to me, agile means X". Which will probably never
| happen - I suspect people will just stop talking about it one
| day and start using different terms for all the concrete
| steps that are sometimes filed under "agile" but which
| actually work.
| zigglezaggle wrote:
| That's a bit misleading. agilemanifesto.org also hosts a
| (still short, but way more concrete) Twelve Principles of
| Agile Software: https://agilemanifesto.org/principles.html
|
| (Also worth noting that scrum and most of the best known
| agile methodologies predate the manifesto; the manifesto was
| formed from guiding principles of those methodologies, not
| the other way around:
| https://agilemanifesto.org/history.html)
| ceoshill wrote:
| How unsurprising, than, that every little town and village
| has their own folk religion built around those 4-5 sentences.
| No wonder this topic is a holy war.
| marcosdumay wrote:
| Dailies have the social contract of "you get to talk to the
| developers every morning, so shut-up the rest of the day", what
| on theory should be really great.
|
| The only problem is that all the problem people never take the
| hint, and the well-behaved people tend to take it to an
| extreme. So on practice it both doesn't get rid of the
| interruptions, and delay everybody's work due to the latency
| you need for avoiding interruptions.
| jimmaswell wrote:
| People have complained to my boss when I've said the standup
| was designed to be as short as possible, maybe 10 minutes max,
| because it was done standing up. It's not called the sitdown.
| But ours can run over an hour. It's agonizing sitting there for
| an hour waiting to hear my name among the 99% of noise entirely
| irrelevant to me.
| TeMPOraL wrote:
| > _It 's agonizing sitting there for an hour waiting to hear
| my name among the 99% of noise entirely irrelevant to me._
|
| More than once I've been asked discretely by my PM if
| everything is OK with me, because half an hour down a team
| meeting whose contents is "99% of noise entirely irrelevant
| to me", I'm too exhausted trying to control my movements to
| keep my body from telegraphing the fact I'm bored out of my
| mind. Turns out, to an outside party, I start looking like I
| haven't slept the night, or am about to get a stroke, or
| something.
| mleonhard wrote:
| The study had only 20 people.
| jjallen wrote:
| I find taking mini breaks, whether visiting the restroom or being
| interrupted by my kids to be quite beneficial actually.
|
| It gives my mind a few seconds or a minute or two to do
| background processing and potentially come up with a better way
| of doing something.
|
| Or to realize that I'm not working on the most important thing in
| the first place.
| napsterbr wrote:
| Sure, and I agree with you, but what you described is just a
| break, not an interruption.
|
| These breaks were taken at a "natural" time, when you felt one
| was needed. By definition, an interruption is a "break" when
| you don't want one.
| macNchz wrote:
| Additionally, a break might be an opportunity for your mind
| to continue working on whatever it was you left off with,
| whereas an interruption explicitly redirects your attention
| to another topic.
|
| When I'm deep in the weeds on a task, stepping away for a
| walk in the park, a workout, or to prepare a meal or some
| coffee, affords me the opportunity to _clear_ the micro
| details of the task from my mind while retaining the macro at
| the tip of my attention. This state is very frequently where
| the best insights on the task emerge, whereas an interruption
| resets both micro and macro attention entirely to something
| else.
| jjallen wrote:
| My son storming into my room unexpectedly is definitely an
| interruption.
| TeMPOraL wrote:
| > _I find taking mini breaks, whether visiting the restroom or
| being interrupted by my kids to be quite beneficial actually._
|
| For me, it depends. When working at home with kids around, I
| actually dread the restroom break or making myself a cup of
| tea, because in those two minutes I'm out of the home office,
| it's virtually guaranteed they'll drag me into whatever is
| happening at home at the given moment, wiping my focus
| entirely.
|
| Sometimes this does break me out of being fixated on doing the
| wrong thing, but more often than not, it just plain prevents me
| from doing _any_ thing at all.
| rednafi wrote:
| We're also a picky bunch. A short coffee break or a chat with
| someone I like doesn't hurt as much as a "quick question" from
| Joe in Sales does.
| marcosdumay wrote:
| One single "quick question" doesn't do a lot of harm...
|
| If you have an average of 4/day or more, it will probably
| consume all of your working time. But one of them isn't a
| problem at all.
|
| And there's the problem, because it's both not a problem in
| small numbers, and a DoS attack still in small numbers.
| rednafi wrote:
| A quick question from a fellow engineer is almost always
| quick; unfortunately, that's not the case for most other
| situations.
| TeMPOraL wrote:
| A "quick question" from non-engineers (and even fresh
| engineers not yet used to the idea of _focusing on work at
| work_ , or in general people who don't understand they're
| not the centre of the world) is usually carrying within it
| a _request_ (or demand) to do something for the other
| person. A genuine "quick question" is one to which a quick
| "I don't know" or "not now!" is an acceptable answer. Those
| are easy to navigate - if you feel like considering it
| fully will break your focus, you can just decline answering
| it. If you can't, it means the question is really a
| disguised attempt to offload work onto you; engaging with
| it is giving permission to the other party to pull you in
| and try to keep you there.
| steve1977 wrote:
| Well, one question probably causes around 10-15 minutes of
| harm (not counting the time to actually answer the question).
|
| So yeah - have 4 of these a day and you've wasted an hour.
| Have this every working day and you've already wasted half a
| day per week.
| edoceo wrote:
| Choosing your break isn't an interruption. An unexpected,
| external tangent is.
| ambicapter wrote:
| This seems like a failure of emotional self-control...
| redelbee wrote:
| Interruptions are productivity and creativity killers. Middle
| managers are of questionable utility but that layer of an
| organization would be much more effective if it focused
| ruthlessly on removing distractions.
|
| I worked at a small company where a significant portion of my
| effort went toward shielding my team from the distractions
| created by a CEO who couldn't seem to help meddling in every
| aspect of the business. I think it's because he started out
| doing, or at least being involved with, many of the functions of
| the company and had a hard time letting go as we grew. Even after
| the organization grew to 50+ people he couldn't keep himself out
| of the nitty gritty details, but the format of the distraction
| changed over time. Instead of walking up to people and
| interrupting them in person (a double whammy according to this
| study, including both an "important" person and the in-person
| aspect), he would send what we called "Slack attacks" throughout
| the day. These were paragraphs-long Slack messages without any
| semblance of organization, punctuation, or line breaks.
| Fortunately, many of these messages were sent during the very
| early hours of the morning so they could be dealt with first
| thing in the AM, but that wasn't always the case.
|
| In the first phase I literally moved my team location and
| reorganized the desk arrangement so it was harder for him to get
| in and bug everyone. I had to "guard" the area and try to stop
| him from physically entering the space, which was always a
| strange dance. I couldn't control his Slack messaging behavior so
| I worked with people to understand that while yes "the CEO is
| asking you for urgent work in Slack" seems like a valid reason to
| switch gears, but instead let me work to figure out what actually
| needs to be done and we'll catch up later about what to do.
|
| It was a weird dynamic but there was no doubt the distractions
| were a drag on performance. Every time he went on vacation we saw
| a marked increase in productivity, and more creative solutions
| seemed to come up as well. I don't wish this type of environment
| on anyone but in a way I'm glad to have gone through it and
| learned some lessons about interruptions and how to avoid them.
| alexpotato wrote:
| In defense of middle managers:
|
| When I was a middle manager at a past job, my team kept getting
| bombarded with meeting requests (it was a "fire drill all the
| time" kind of place).
|
| I ended up making a 4 hour "team meeting" every Friday morning
| to give them focus time.
|
| I mentioned to them that they could have done the same on their
| own if they wanted. My team lead pointed out that since our
| calendars were visible in the department, having me as the
| organized gave the meeting more "weight" and so line employees
| were less likely to push for time in that slot.
| TeMPOraL wrote:
| That's a good point, thanks for saying it. Speaking as one of
| such developers who had trouble with it for a long time,
| plenty of us might end up feeling shy or insecure about
| making proactive interventions to secure time for ourselves
| or our teams - all while our managers might be _assuming_ we
| 'll make such moves when needed. Sometimes all it takes is an
| explicit permission from a person in position of power - them
| saying to subordinates, "it's fine if you block off focus
| time for the team in the company calendar". And, per your
| example, it's even better when followed by assurances of
| support, such as being an organizer or confirmed invitee. For
| better or worse, a lot of inter-team dynamics ends up being
| about looks.
| portaouflop wrote:
| Half my day is blocked with "no meetings please unless
| urgent" and it works great - but I guess it's part of the
| org culture that we respect each others time and don't do a
| lot of unnecessary meetings in general anyway so idk if it
| would work that well somewhere else
| cauch wrote:
| That's an interesting experience and a valuable info.
|
| But I wonder what would be the CEO's side of the story. I'm
| sure his behavior was bad, I'm not pretending the opposite. But
| maybe he also had reasons (misguided reasons, sure, but still
| reasons) to act as he did. Or maybe he did not have any
| reasons, it's also possible.
|
| I've observed cases where indeed people were disturbing too
| much software developers.
|
| But I've also observed cases where software developers were not
| enough aligned with the business side, despite them being 100%
| sure they were.
|
| It's a tricky situation: being in the team means that you are
| not impartial, you don't have a remote view, you are only
| seeing one side of the story. I had situations where I've
| observed some non-dev team explaining their needs, then the
| software team went away, and then came back with something that
| was not what the non-dev team asked. Not only the non-dev team
| was indeed not satisfied, but I was agreeing to them: it was
| not what they explained, I was there, I understood what they
| said at the time. Worst, in the majority of the cases, the non-
| devs don't just say "no, it's incorrect", they try to find a
| compromise. Usually, it comes from the fact they have no idea
| what is possible or not, and just assume that if the devs did
| not do what they were expected, it means there are good reasons
| for that (either it is not possible, or that there were others
| things they did not know about, such as other requests from
| other part of the business). As someone with a lot of
| developing experience, I was able to see that the problem was
| that the devs just underestimated the need to fully understand
| the business side.
|
| It's very tricky, because for a dev (or a dev-side person), it
| is very easy to just ignore that. If they ask for adjustment,
| it's "they don't know what they want". If they point at some
| requirements and underline that it does not mean what the devs
| thought it meant, it's "these requirements were badly written".
| And in the majority of the case, the business-side just makes
| do with the sub-optimal solution and the dev-side is
| considering that they successfully delivered. And similarly,
| I've also seen some devs being happy to be very productive,
| going very fast in developing something ... that the business
| did not need at all. When not adopted, it was again blamed on
| the business-side for not using the solution they've developed,
| rather than to wonder if what they have done was indeed
| productive or not.
| SoftTalker wrote:
| It's a manifestation of insecurity and lack of trust in the
| team.
| ceoshill wrote:
| This isn't tricky at all. If the CEO were concerned that
| developers weren't doing their jobs correctly, that's a
| really easy Slack message.
|
| Why is it hard to accept that maybe being a CEO doesn't mean
| you're good at your job?
| catchcatchcatch wrote:
| There's people that don't have adhd that can handle
| notifications. That's the thing with being impulsive - those
| disorders are mental illnesses (quite technically) and will limit
| your net worth. It's like why do all developers need to be
| listening to the orchestra or radio while programming?
| crackez wrote:
| Hard disagree.
|
| It's not at all a mental illness. That's ignorant.
|
| Some of the most technically adept people I know are on the
| spectrum and they are incredibly valuable. We're talking Chief
| architects, lead/senior engineers, Network engineers, and the
| list goes on.
|
| People like that probably have divergent neurochemistry
| compared to you.
|
| Learn to leverage that asset and stop being a Karen.
|
| Feigned wisdom isn't.
| steve1977 wrote:
| To be excellent, you are by definition "not normal".
| steve1977 wrote:
| Maybe those people who "can handle notifications" are just less
| much less productive as a baseline to start with? Hence they
| don't feel the impact as much.
|
| I often find this with people who think they are good at
| "multitasking".
| jimmaswell wrote:
| I certainly handle distractions better with my ADHD
| medication, personally.
| arkh wrote:
| > It's like why do all developers need to be listening to the
| orchestra or radio while programming?
|
| On one hand: well, when you have to keep big mental models in
| your head you don't want to be interrupted. The big headphones
| serve to indicate you are in the middle of work.
|
| On the other hand: have you ever been on a construction site?
| You'll hear some radio usually.
| Izkata wrote:
| Yeah, wearing headphones doesn't necessarily mean they're
| actually listening to anything.
| SoftTalker wrote:
| You can turn notifications off.
| postalrat wrote:
| I believe handling interruptions is a skill that is learned.
| Isolating yourself prevents you from learning it.
| 65 wrote:
| Microsoft Teams is perhaps the worst communication software your
| company can have for Software Engineers. People usually don't use
| the half-baked threads capabilities because they're separate and
| not intuitive, so it's usually just endless chat messages, all at
| once. And so you get constant pinging all day. And then I need to
| mute my Teams chats, which is also risky because I could have
| gotten an important message.
___________________________________________________________________
(page generated 2025-01-20 23:02 UTC)