6 ms·

Software development untethered from the practical realities of the customer / user is what drives people insane. When developers are required to interact with

Software development untethered from the practical realities of the customer / user is what drives people insane. When developers are required to interact with the customer on a regular basis, the freewheeling effects described in this article are damped massively. The potential for insanity goes off the charts when the development team is siloed away in solitary confinement and the only interactions with the client occur via some prison guard known as "project manager" sliding notes under the door. Working with the customer sometimes sucks. Just like exercise and eating vegetables sometimes suck. It's a temporary unhappiness that keeps us grounded in reality.

mediaman 6d ago
Agreed. I find it really fun to work with customers. It keeps you focused on real problems. And there are so many problems in 'boring' industries that need solving. Just a ridiculous number. There's so much bad software out there, or things being done manually, still now so many decades into the industry. But you have to be willing to break out of the bubble, including getting on a plane, and I see very few people being willing to do that.
mschuster91 6d ago
> The potential for insanity goes off the charts when the development team is siloed away in solitary confinement and the only interactions with the client occur via some prison guard known as "project manager" sliding notes under the door. But... but what would Project Managers do, then? Anyway the key thing for any software developer AND Project Managers to do is regularly work first level helpdesk.
- AnimalMuppet 6d ago
  What would Project Managers do? Manage backlog. Set priorities. See that the one customer gripe from someone's eccentric old Uncle George does not re-architect the entire UI, no matter how fervently Uncle George believes in it. Do the same as the previous sentence, when "Uncle George" is in upper management.
cosmic_cheese 6d ago
Absolutely. I think that over-reliance on analytics has had a similar effect; compared to relying primarily on proper usability research and in-person user studies, doing that creates a detachment and distance that further removes the project from reality. How great the impact is depends on how management uses the data. If they use it add resolution to broad strokes from studies and the like, there may be no negative impact at all, but in my experience it's much, much more common for management to read analytics like tea leaves and interpret it in whatever way best fits the individual's/team's biases/agendas.
- anonymars 6d ago
  Simple example: feature X is rarely used (thus we should get rid of it) Hold on, why is it rarely used? Is it hard to use? Is it hard to find? Was it poorly named? Does it work right? Does it get me 80% of the way there? Does it get me 20% of the way there? Do I rarely need it but when I do need it it's a huge time saver? Am I hesitant to depend on it because I fear it will be taken away in a future update?
  - cosmic_cheese 6d ago
    And following this, I'm sure we've all seen the pattern of manufacturing the data required to justify the removal of features. Bury feature → usage numbers tank → oh hey look nobody uses this any more, guess we can safely cut it!
  - mjr00 6d ago
    > Simple example: feature X is rarely used (thus we should get rid of it) Oh man, I remember a very specific example of this: many years ago now, Google Chrome pushed an update that got rid of the option on the menu bar for "Close Tabs to the Right". I remember looking into the Google issue tracker where people were complaining, and some PM provided a "data-driven" justification: when people opened the context menu, they only clicked on the "Close Tabs to the Right" option 1-2% of the time. It's a great example of why data without context can give you the wrong answer. Of course the option is used relatively very rarely; you only need to clear out your tabs every once in a while, compared to creating new ones or managing tab groups! But it's still an essential task. It's like saying filing your taxes isn't important because you only need to do it 0.2% days of the year.
bombela 6d ago
Talking to the users, allowing them to show you what they are trying to do with your software, almost feels like cheating, because of how easy things suddenly appear to be when uncertainty fades away. Obviously, the number of uniquely different users has an influence, and users most often do not truly know what they need, but that's our job to tease appart. Turns out the users most often benefits from small changes that reduces friction toward achieving their goal. Any time saving will be appreciated, but only if it can be trusted to work. Nothing worse than the dread of knowing an action might or might not work randomly. I use most software today with a constant sense of fear that the next action will break something and waste my time. Undo probably doesn't work properly anyways
- devmor 6d ago
  "What problem are we trying to solve?" is a question I have to ask constantly in corporate development environments, and rarely does anyone presenting the task to be done actually know the answer! It's very frustrating.
  - robertlagrant 6d ago
    It can be the case that people don't want to accidentally mis-state the problem, or get into a debate about the problem because they know people will chime in about nonessentials. I would recommend "Have we written down the problem we are trying to solve? I'd like to understand more." And get it written down if it isn't already.
    - some_furry 6d ago
      Trying to position the conversation as "we're on the same team, trying to figure the problem out together" also helps a lot of the intensity of these conversations melt away.
    - computomatic 6d ago
      This is likely the start to a useful approach. I suspect the crux of the challenge is that engineers who need to write code get very pedantic in their questions and picking the answers apart (because we need to be! code leaves no room for ambiguity or intuition). And you can imagine how that feels from the other side. I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate. A natural response will be to try to dictate what to build (often micromanaging) and avoid the discussion about why at all costs. Writing offers a bit of a neutralizing buffer, at least.
martijnvds 6d ago
I think this goes both ways. More actual interaction between end-users and programmers makes the end-users better at reporting bugs and describing what they want (and at having an idea how complex a certain request actually is). Because the multiple translations from customer wish to project manager language to backlog items are all lossy.
jghn 6d ago
The problem is it's often the devs themselves who request the siloing. I used to assume otherwise, as I think the way you do. And then I had a lot of my devs rebelling because I was keeping them from their "real work" by having them deal with users.
- Brian_K_White 6d ago
  I just call them not great developers. The users pay your fat salary and you yourself are a user for everything else in the world and at all other times. It's not some icky burden to talk to them or let them talk to you, it's the job. If you don't like the job, then you don't like the job, and should not be doing the job. I don't have a lot of patience or sympathy for this attitude even though it's practically universal. There might be a few legitimate cases where someone basically has a handicap where they are clinically incapable, but then that's a handicap like a broken leg. A defect. Maybe it's ok to make allowances for them in the name of equality but it's absolutely making allowances, and should not be a norm and should not be something just everyone gets to claim for their mere comfort and convenience. IMO anyway if I were king and all that.
  - anonymars 6d ago
    Maybe, but check if there's another level to it: is it because their performance review is based on metrics for which meeting with customers is a hindrance? If I'm graded on getting tickets done or getting some feature out, then meeting with users may be beneficial and the right thing to do but incentives turn it into swimming upstream...
  - fragmede 6d ago
    > The users pay your fat salary In an idealized world, maybe, but enterprise software isn't paid for by its actual users, but by their company's executives/management.
  - ronjakoi 6d ago
    I live in Finland, where in "product companies" developers don't always speak great English. Or they might not speak Finnish if they're immigrants. So the employer wants to pick and choose product managers that they think are "presentable" enough in terms of linguistic or social competence to put directly in front of a customer. They seem to value this high enough that they are willing to take the productivity hit from the indirection.
j45 6d ago
Beautifully articulated. Software that is not about the user and more about the developers or the providers struggles with alignment and optimizing for the outcomes of the user instead of their own.
sodapopcan 6d ago
> Working with the customer sometimes sucks. Sometimes it sucks, but often it's awesome. I love seeing people use what I built for them. It was also very enlightening doing prototyping and watching the customers use it. Often they would ask for something that they didn't realize they didn't actually want until they used it. Working directly with them saved potentially months of building out features that would never be used.
icantevenhold 6d ago
I disagree - it’s best never to talk to users because they have no idea what good quality is and will constantly push you to implement stupid features that only they uniquely need because of their fucked up business practices. Or weaken your security so it works with their fucked up legacy firewall that cant ever be changed and so on. Talking to users -> not even once. Might be only this bad in B2B software
- hulitu 5d ago
  > it’s best never to talk to users because they have no idea what good quality is You should use some Microsoft, Google, Adobe and Apple products to have an idea what good quality _isn't_.
lezojeda 6d ago
[dead]
strangattractor 6d ago
Sometimes I would ask stakeholders about some idea or nifty feature we were considering implementing. The answer was usually positive and enthusiastic. I'd then ask if they would use it and how it would help them. Silence.... Being untethered from reality is the natural state of humans;)
- vector_spaces 6d ago
  "What if I made X?" is basically Product Development Antipattern #1. Most feedback you get here is incredibly low signal. The stakeholder you're talking to isn't a technical person in all likelihood, so they probably aren't visualizing what you're describing in the same way you are. There is a high probability that they are telling you it sounds great as social lubricant or because they don't really understand what you are talking about and don't want to look dumb. Not to mention that positive response is the path of least resistance for most people -- the hard work of thinking critically about an idea so that you can locate potential flaws requires caring in the first place, and most people assume positive feedback is what you want to hear anyway.
jrm4 6d ago
Sure. Now, how to deal with the entirely plausible situation where there needs not be any separation between the developer and the customer at all, thanks to AI.
PaulHoule 6d ago
A similar disease comes out of an industry being overly concentrated in a single geography. For instance Firefox could keep failing and losing market share for decades because Google knows politicians will be stupid enough to believe that Firefox with a 0.01% market share will mean Chrome is not a monopoly. The one thing that could possible reverse that market share decline would be having some empathy for people outside the Bay Area but that won't happen... but it doesn't matter.
- hulitu 5d ago
  > Firefox Nobody asked Mozilla for a redesign.
stinos 6d ago
For 2 larger projects I'm on, I'm both the developer and a user: on a regular basis I use the software myself. And not just for one-off tests. I really use it the way other users use it. This has provided rather deep and interesting insights in software development for these particular products and in general. Or in OP's lingo: not a lot of potential for insanity at all. Because any new idea immediately gets regarded on 2 fronts: what does it take to implement and what does it really do for the user.
- nyeah 6d ago
  This approach is really worth pointing out and recommending. Not everyone is allowed / encouraged to realize how powerful it is.
- Sleaker 6d ago
  This is something I've asked repeatedly at my job. Current team builds services for other developers to use, okay, do we also use it so we can go th ough all the same pain points as them? Why not?!
- da_chicken 6d ago
  In my experience, this is the only kind of software that ends up not sucking. If development is not driven by users in a very intimate way -- like being one and the same person -- then you routinely end up with necessary features only half working or splitting essential information across multiple screens or dialogs. Eating your own dog food is essential to rising above that, because only that reality will overwhelm the developers sense of the "proper" way to do things. I believe it's the major reason that industry specific information systems are universally shitty. The user can't articulate what they need to accomplish and the developer doesn't really understand the purpose or importance of the work. Result is bad functioning or bad interface. It's why only software like text editors and web browsers gets to be really good. Huge user base. Lots of developers involved. Git kinda proves that it's not infallible, though.
  - win311fwg 6d ago
    > It's why only software like [...] web browsers gets to be really good. Huh? Web browsers are still laughably bad even after all these years. They are engineering marvels, certainly, but using them leaves a lot to be desired. I cannot imagine anyone would voluntarily use them if the ultimate function was equally available another way.
seki285 6d ago
Not sure on this, a lot of time I know better but the customer insists we do it their way and it's usually because they are lazy to improve on their end.
beyonddream 6d ago
When the user is understood as yet another human who doesn’t know what they want, the insanity returns! Because an average customer usually doesn’t have practically grounded wants.
surcap526 6d ago
[dead]
Twirrim 6d ago
I've had more than one half-serious conversation with SVPs here that every staff/architect level engineer should have to spend at least 6 months working on the engineering team that directly interacts with the largest customers. I flat out guarantee they'll come away with a wildly different perspective of the things that need done, and the ways their service operates. Ideally I'd want them to do a rotation in customer support so they get the small customer perspective too, and at least learn what kind of paper cuts they're inflicting on customers.
maxgashkov 6d ago
Oh boy, I do mostly agree with you but this applies well if you’re making software for the fellow SWEs. While a lot of them can be an annoying bunch, once you’re making something for general consumption, like let’s say running an e-commerce platform, interacting with your end users could be probably better compared to a front desk/service industry job. It’s very hard to keep that positive attitude then.
vismit2000 6d ago
https://www.productftw.com/cdn-cgi/image/format=auto%2Cwidth=960%2Cquality=85/content/images/2024/01/tree_swing_development_requirements-1.jpg https://www.productftw.com/cdn-cgi/image/format=auto%2Cwidth...
zanellato19 5d ago
The stakeholders should be held accountable to this. C level and PMs. Otherwise they just push what they believe will be better, no matter what developers say.

mediaman 6d ago

Agreed. I find it really fun to work with customers. It keeps you focused on real problems. And there are so many problems in 'boring' industries that need solving. Just a ridiculous number. There's so much bad software out there, or things being done manually, still now so many decades into the industry. But you have to be willing to break out of the bubble, including getting on a plane, and I see very few people being willing to do that.

mschuster91 6d ago

> The potential for insanity goes off the charts when the development team is siloed away in solitary confinement and the only interactions with the client occur via some prison guard known as "project manager" sliding notes under the door. But... but what would Project Managers do, then? Anyway the key thing for any software developer AND Project Managers to do is regularly work first level helpdesk.

AnimalMuppet 6d ago
What would Project Managers do? Manage backlog. Set priorities. See that the one customer gripe from someone's eccentric old Uncle George does not re-architect the entire UI, no matter how fervently Uncle George believes in it. Do the same as the previous sentence, when "Uncle George" is in upper management.

cosmic_cheese 6d ago

Absolutely. I think that over-reliance on analytics has had a similar effect; compared to relying primarily on proper usability research and in-person user studies, doing that creates a detachment and distance that further removes the project from reality. How great the impact is depends on how management uses the data. If they use it add resolution to broad strokes from studies and the like, there may be no negative impact at all, but in my experience it's much, much more common for management to read analytics like tea leaves and interpret it in whatever way best fits the individual's/team's biases/agendas.

anonymars 6d ago
Simple example: feature X is rarely used (thus we should get rid of it) Hold on, why is it rarely used? Is it hard to use? Is it hard to find? Was it poorly named? Does it work right? Does it get me 80% of the way there? Does it get me 20% of the way there? Do I rarely need it but when I do need it it's a huge time saver? Am I hesitant to depend on it because I fear it will be taken away in a future update?
- cosmic_cheese 6d ago
  And following this, I'm sure we've all seen the pattern of manufacturing the data required to justify the removal of features. Bury feature → usage numbers tank → oh hey look nobody uses this any more, guess we can safely cut it!
- mjr00 6d ago
  > Simple example: feature X is rarely used (thus we should get rid of it) Oh man, I remember a very specific example of this: many years ago now, Google Chrome pushed an update that got rid of the option on the menu bar for "Close Tabs to the Right". I remember looking into the Google issue tracker where people were complaining, and some PM provided a "data-driven" justification: when people opened the context menu, they only clicked on the "Close Tabs to the Right" option 1-2% of the time. It's a great example of why data without context can give you the wrong answer. Of course the option is used relatively very rarely; you only need to clear out your tabs every once in a while, compared to creating new ones or managing tab groups! But it's still an essential task. It's like saying filing your taxes isn't important because you only need to do it 0.2% days of the year.

bombela 6d ago

Talking to the users, allowing them to show you what they are trying to do with your software, almost feels like cheating, because of how easy things suddenly appear to be when uncertainty fades away. Obviously, the number of uniquely different users has an influence, and users most often do not truly know what they need, but that's our job to tease appart. Turns out the users most often benefits from small changes that reduces friction toward achieving their goal. Any time saving will be appreciated, but only if it can be trusted to work. Nothing worse than the dread of knowing an action might or might not work randomly. I use most software today with a constant sense of fear that the next action will break something and waste my time. Undo probably doesn't work properly anyways

devmor 6d ago
"What problem are we trying to solve?" is a question I have to ask constantly in corporate development environments, and rarely does anyone presenting the task to be done actually know the answer! It's very frustrating.
- robertlagrant 6d ago
  It can be the case that people don't want to accidentally mis-state the problem, or get into a debate about the problem because they know people will chime in about nonessentials. I would recommend "Have we written down the problem we are trying to solve? I'd like to understand more." And get it written down if it isn't already.
  - some_furry 6d ago
    Trying to position the conversation as "we're on the same team, trying to figure the problem out together" also helps a lot of the intensity of these conversations melt away.
  - computomatic 6d ago
    This is likely the start to a useful approach. I suspect the crux of the challenge is that engineers who need to write code get very pedantic in their questions and picking the answers apart (because we need to be! code leaves no room for ambiguity or intuition). And you can imagine how that feels from the other side. I imagine a lot of people feel like an engineer asking about the actual problem feels like getting goaded into some sort of pedantic debate. A natural response will be to try to dictate what to build (often micromanaging) and avoid the discussion about why at all costs. Writing offers a bit of a neutralizing buffer, at least.

martijnvds 6d ago

I think this goes both ways. More actual interaction between end-users and programmers makes the end-users better at reporting bugs and describing what they want (and at having an idea how complex a certain request actually is). Because the multiple translations from customer wish to project manager language to backlog items are all lossy.

jghn 6d ago

The problem is it's often the devs themselves who request the siloing. I used to assume otherwise, as I think the way you do. And then I had a lot of my devs rebelling because I was keeping them from their "real work" by having them deal with users.

Brian_K_White 6d ago
I just call them not great developers. The users pay your fat salary and you yourself are a user for everything else in the world and at all other times. It's not some icky burden to talk to them or let them talk to you, it's the job. If you don't like the job, then you don't like the job, and should not be doing the job. I don't have a lot of patience or sympathy for this attitude even though it's practically universal. There might be a few legitimate cases where someone basically has a handicap where they are clinically incapable, but then that's a handicap like a broken leg. A defect. Maybe it's ok to make allowances for them in the name of equality but it's absolutely making allowances, and should not be a norm and should not be something just everyone gets to claim for their mere comfort and convenience. IMO anyway if I were king and all that.
- anonymars 6d ago
  Maybe, but check if there's another level to it: is it because their performance review is based on metrics for which meeting with customers is a hindrance? If I'm graded on getting tickets done or getting some feature out, then meeting with users may be beneficial and the right thing to do but incentives turn it into swimming upstream...
- fragmede 6d ago
  > The users pay your fat salary In an idealized world, maybe, but enterprise software isn't paid for by its actual users, but by their company's executives/management.
- ronjakoi 6d ago
  I live in Finland, where in "product companies" developers don't always speak great English. Or they might not speak Finnish if they're immigrants. So the employer wants to pick and choose product managers that they think are "presentable" enough in terms of linguistic or social competence to put directly in front of a customer. They seem to value this high enough that they are willing to take the productivity hit from the indirection.

j45 6d ago

Beautifully articulated. Software that is not about the user and more about the developers or the providers struggles with alignment and optimizing for the outcomes of the user instead of their own.

sodapopcan 6d ago

> Working with the customer sometimes sucks. Sometimes it sucks, but often it's awesome. I love seeing people use what I built for them. It was also very enlightening doing prototyping and watching the customers use it. Often they would ask for something that they didn't realize they didn't actually want until they used it. Working directly with them saved potentially months of building out features that would never be used.

icantevenhold 6d ago

I disagree - it’s best never to talk to users because they have no idea what good quality is and will constantly push you to implement stupid features that only they uniquely need because of their fucked up business practices. Or weaken your security so it works with their fucked up legacy firewall that cant ever be changed and so on. Talking to users -> not even once. Might be only this bad in B2B software

hulitu 5d ago
> it’s best never to talk to users because they have no idea what good quality is You should use some Microsoft, Google, Adobe and Apple products to have an idea what good quality _isn't_.

lezojeda 6d ago

[dead]

strangattractor 6d ago

Sometimes I would ask stakeholders about some idea or nifty feature we were considering implementing. The answer was usually positive and enthusiastic. I'd then ask if they would use it and how it would help them. Silence.... Being untethered from reality is the natural state of humans;)

vector_spaces 6d ago
"What if I made X?" is basically Product Development Antipattern #1. Most feedback you get here is incredibly low signal. The stakeholder you're talking to isn't a technical person in all likelihood, so they probably aren't visualizing what you're describing in the same way you are. There is a high probability that they are telling you it sounds great as social lubricant or because they don't really understand what you are talking about and don't want to look dumb. Not to mention that positive response is the path of least resistance for most people -- the hard work of thinking critically about an idea so that you can locate potential flaws requires caring in the first place, and most people assume positive feedback is what you want to hear anyway.

jrm4 6d ago

Sure. Now, how to deal with the entirely plausible situation where there needs not be any separation between the developer and the customer at all, thanks to AI.

PaulHoule 6d ago

A similar disease comes out of an industry being overly concentrated in a single geography. For instance Firefox could keep failing and losing market share for decades because Google knows politicians will be stupid enough to believe that Firefox with a 0.01% market share will mean Chrome is not a monopoly. The one thing that could possible reverse that market share decline would be having some empathy for people outside the Bay Area but that won't happen... but it doesn't matter.

hulitu 5d ago
> Firefox Nobody asked Mozilla for a redesign.

stinos 6d ago

For 2 larger projects I'm on, I'm both the developer and a user: on a regular basis I use the software myself. And not just for one-off tests. I really use it the way other users use it. This has provided rather deep and interesting insights in software development for these particular products and in general. Or in OP's lingo: not a lot of potential for insanity at all. Because any new idea immediately gets regarded on 2 fronts: what does it take to implement and what does it really do for the user.

nyeah 6d ago
This approach is really worth pointing out and recommending. Not everyone is allowed / encouraged to realize how powerful it is.
Sleaker 6d ago
This is something I've asked repeatedly at my job. Current team builds services for other developers to use, okay, do we also use it so we can go th ough all the same pain points as them? Why not?!
da_chicken 6d ago
In my experience, this is the only kind of software that ends up not sucking. If development is not driven by users in a very intimate way -- like being one and the same person -- then you routinely end up with necessary features only half working or splitting essential information across multiple screens or dialogs. Eating your own dog food is essential to rising above that, because only that reality will overwhelm the developers sense of the "proper" way to do things. I believe it's the major reason that industry specific information systems are universally shitty. The user can't articulate what they need to accomplish and the developer doesn't really understand the purpose or importance of the work. Result is bad functioning or bad interface. It's why only software like text editors and web browsers gets to be really good. Huge user base. Lots of developers involved. Git kinda proves that it's not infallible, though.
- win311fwg 6d ago
  > It's why only software like [...] web browsers gets to be really good. Huh? Web browsers are still laughably bad even after all these years. They are engineering marvels, certainly, but using them leaves a lot to be desired. I cannot imagine anyone would voluntarily use them if the ultimate function was equally available another way.

seki285 6d ago

Not sure on this, a lot of time I know better but the customer insists we do it their way and it's usually because they are lazy to improve on their end.

beyonddream 6d ago

When the user is understood as yet another human who doesn’t know what they want, the insanity returns! Because an average customer usually doesn’t have practically grounded wants.

surcap526 6d ago

[dead]

Twirrim 6d ago

I've had more than one half-serious conversation with SVPs here that every staff/architect level engineer should have to spend at least 6 months working on the engineering team that directly interacts with the largest customers. I flat out guarantee they'll come away with a wildly different perspective of the things that need done, and the ways their service operates. Ideally I'd want them to do a rotation in customer support so they get the small customer perspective too, and at least learn what kind of paper cuts they're inflicting on customers.

maxgashkov 6d ago

Oh boy, I do mostly agree with you but this applies well if you’re making software for the fellow SWEs. While a lot of them can be an annoying bunch, once you’re making something for general consumption, like let’s say running an e-commerce platform, interacting with your end users could be probably better compared to a front desk/service industry job. It’s very hard to keep that positive attitude then.

vismit2000 6d ago

https://www.productftw.com/cdn-cgi/image/format=auto%2Cwidth=960%2Cquality=85/content/images/2024/01/tree_swing_development_requirements-1.jpg https://www.productftw.com/cdn-cgi/image/format=auto%2Cwidth...

zanellato19 5d ago

The stakeholders should be held accountable to this. C level and PMs. Otherwise they just push what they believe will be better, no matter what developers say.