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.
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.
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
"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!
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.
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?
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.
> The problem is it's often the devs themselves who request the siloing
I used to be this developer.
The more the development team complains, the more valuable the system is. If there is never any friction between the developers and customers, it's likely that everyone is on the same page and the meeting is largely redundant.
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.
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...
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.
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.
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.
> 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.
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.
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.
I was about to post this thought on the latest "We're moving from tech/architecture X to Y" post on the HN front page today, but now I feel it belongs here.
I was recently chatting with a friend about how we used to do so much more with so few developers: 20 years ago, we developed mission critical, real time software (trading systems) in C++ with team of a couple of dozen developers. The core trading kernel team was four people. An in-house distributed process orchestration tool (both front end and back end written in C++) were two guys. I myself once managed to produce an entire post-trade risk management system for futures contracts in a couple of months, working alone. Today, I see teams of 60-80 working on web and mobile applications where the vast majority of operations are CRUD, with some transaction/queue complexity at the extremities.
I think the difference is tech churn. Back then, what few dependencies we had in terms of either runtime libraries or development time tools, were stable: the standard library, compiler, unix commands and bash scripts, and some internal libraries. Much of our time and focus went into figuring out the right algorithms and data structures, with coding coming in second. Very little time was spent on selecting, configuring, updating, rearchitecting or replacing tech stacks and tools.
My observation is simply that tech leaders misinterpret rewards from the market in conquering some abstract representation of a facet of a domain with conquering the domain itself. Then they become egomaniacal.
Did you conquer commercial real-estate ushering in the future of work and society, or did you build a handy scheduling app?
Did you have a neat idea for an online community or did you revolutionize human connection?
I think it takes a certain type of mental or emotional deficit to forfeit all of your free time and the majority stake in your company for funding for a tiny shot at hitting a grand-lam.
"Not everything needs to be a platform". I remember a 10 person company that did translation dispatch for medical needs in California. And the CEO was insisting we needed to someday "become a platform."
> Not in the "wash your hands every thirty minutes like Howard Hughes" kind of way,
Hold on, this isn't that crazy in today's day and age. I used to wash my hands basically only when using the restroom or before eating. Since the pandemic though, I started upping that a lot (not every 30 minutes, but pretty frequently) and since then almost never get sick.
The Cochrane review of "physical interventions to interrupt or reduce the spread of respiratory viruses" that infamously does not find a significant effect for masking does find significant effects for hand washing.
Anecdote: During the pandemic I added washing my hands every time I get back to my office building (and specifically after interacting with surfaces the public interacts with) to my usual hand washing (after bathrooms and before eating, just like you). I keep a towel in my hand for any door handles between the restroom and my office door. Since doing this I feel like I've noticed fewer illnesses, too.
ya, almost every app is over-opinionated on design and only getting worse not better in most case, iOS 26 is perhaps the most egregious mass-market example
thinking to this day afaik still can't change width of first column on Monday.com even tho they claim to replace spreadsheets and only js console will fix
or Trello going the opposite direction of former CTO when any page specifically had sub-second load target. now many seconds, that insane auto markdown editor showing up on almost all input boxes except HN that can't disable no chatgpt i dont want automated bullets i wanted plaintext so can c/p etc.
I wanted the author to see how this relates elsewhere and identify the forces at work.
The solution is not just "do only what's needed by the customer".
There are emerging environments where the conditions don't force previously-rational decisions, and where assumptions no longer apply. New tools in the battlefields of yore, new beliefs and practices in cultures...
The stunning march of compute hardware in the last 50 years has changed many such conditions.
Those who work with new freedom - liberated from the strictures of old gods, able to harm enemies without putting themselves at risk, with the time freed from foraging to build - have to identify the new constraints and conditions at work.
And sometimes to make the conditions that make for sanity: Solon got ancient Greece out of a stagnating pickle by getting the wealthy to release the poor from debtors' jails but sign them up for the military that could defend lands and trade routes, if they subjected themselves to land-owner self-government and the annual ostracism of one person who went too far.
Capitalism used competitive markets to liberate but discipline business, but right now the scaling power of compute leads to winner-take-all, and the openness of the West is seeding closed systems (military or foreign) with the power to destroy the liberal governance that sustains it. In software we're stuck between Scylla and Charybdis: an Anthropic+OpenAI duopoly or Chinese control over the lifeblood of enterprise.
If there were someone who in the large had structured the freedom of software to make its practitioners and stakeholders sane, they'd be a good candidate to steer us through this situation, so this freedom wouldn't drive us insane.
Beautifully written post and true on many levels. The art of software stopped being an art once large amounts of capital started creeping in. There are no signs that we're returning to sanity any time soon.
As a founder of a few software startups, I agree with this. If I can give advice to other founders, remember than software is usually a means to an end, and for most users, they just want the bare bone essentials to work and work well. Everything else is nice-to-have-fluff that won't drive 99% of sales.
The apps I pay for are simple and focus on a super basic interface. BookFusion and Libro.fm are great examples.
It’s interesting because my experience is inverse (b2b software) - the bloated shiny solution what actually doesnt work at all performs better in the market than the sober, unsexy solution that just works.
Companies like Oracle or Microsoft are so massive not because they sell simple and focused products that work well; quite the opposite
Might be different when you’re selling to endusers
Oracle (and SAP and IBM) are not in the business of building software, they are in the business of never complete software, instead stretch the project as far as you can and bill to death.
The insanity the author is describing sounds like normal corporate BS to me. Everybody wants to "raise concerns," everybody is looking for an idea to take credit for, everybody has a reason your idea won't succeed. I'm pretty sure this is the same whether you're making software or advertising campaigns or plastic cups.
I once tried to explain a pointless debate over the definitions of "acceptance testing" versus "regression testing" to a non-tech person, and they said that was the most relatable thing I'd ever told them about my job.
I’ve always thought that this principle explains all sorts of cultural phenomena, from the tech industry having a poorer work-balance compared to others (the pace of development is only limited by how many hours you must sleep!) and programmers seemingly having worse engineer’s disease than in other disciplines (if software can do anything and know everything, how could we, the lever-makers, be any less than our creations?).
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.
> 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.
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
"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.
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.
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?
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.
> The problem is it's often the devs themselves who request the siloing
I used to be this developer.
The more the development team complains, the more valuable the system is. If there is never any friction between the developers and customers, it's likely that everyone is on the same page and the meeting is largely redundant.
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.
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...
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.
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.
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.
> 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.
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.
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
I was about to post this thought on the latest "We're moving from tech/architecture X to Y" post on the HN front page today, but now I feel it belongs here.
I was recently chatting with a friend about how we used to do so much more with so few developers: 20 years ago, we developed mission critical, real time software (trading systems) in C++ with team of a couple of dozen developers. The core trading kernel team was four people. An in-house distributed process orchestration tool (both front end and back end written in C++) were two guys. I myself once managed to produce an entire post-trade risk management system for futures contracts in a couple of months, working alone. Today, I see teams of 60-80 working on web and mobile applications where the vast majority of operations are CRUD, with some transaction/queue complexity at the extremities.
I think the difference is tech churn. Back then, what few dependencies we had in terms of either runtime libraries or development time tools, were stable: the standard library, compiler, unix commands and bash scripts, and some internal libraries. Much of our time and focus went into figuring out the right algorithms and data structures, with coding coming in second. Very little time was spent on selecting, configuring, updating, rearchitecting or replacing tech stacks and tools.
My observation is simply that tech leaders misinterpret rewards from the market in conquering some abstract representation of a facet of a domain with conquering the domain itself. Then they become egomaniacal.
Did you conquer commercial real-estate ushering in the future of work and society, or did you build a handy scheduling app?
Did you have a neat idea for an online community or did you revolutionize human connection?
+1 .
I think it takes a certain type of mental or emotional deficit to forfeit all of your free time and the majority stake in your company for funding for a tiny shot at hitting a grand-lam.
"Not everything needs to be a platform". I remember a 10 person company that did translation dispatch for medical needs in California. And the CEO was insisting we needed to someday "become a platform."
> Not in the "wash your hands every thirty minutes like Howard Hughes" kind of way,
Hold on, this isn't that crazy in today's day and age. I used to wash my hands basically only when using the restroom or before eating. Since the pandemic though, I started upping that a lot (not every 30 minutes, but pretty frequently) and since then almost never get sick.
The Cochrane review of "physical interventions to interrupt or reduce the spread of respiratory viruses" that infamously does not find a significant effect for masking does find significant effects for hand washing.
Anecdote: During the pandemic I added washing my hands every time I get back to my office building (and specifically after interacting with surfaces the public interacts with) to my usual hand washing (after bathrooms and before eating, just like you). I keep a towel in my hand for any door handles between the restroom and my office door. Since doing this I feel like I've noticed fewer illnesses, too.
> Leaving things alone is an underrated engineering skill.
Truer words have never been spoken.
It’s an underrated life skill and was discovered by Lao Tsé probably around 2500 years ago
"It is often easier to not do something stupid than it is to do something smart."
ya, almost every app is over-opinionated on design and only getting worse not better in most case, iOS 26 is perhaps the most egregious mass-market example
thinking to this day afaik still can't change width of first column on Monday.com even tho they claim to replace spreadsheets and only js console will fix
or Trello going the opposite direction of former CTO when any page specifically had sub-second load target. now many seconds, that insane auto markdown editor showing up on almost all input boxes except HN that can't disable no chatgpt i dont want automated bullets i wanted plaintext so can c/p etc.
I wanted the author to see how this relates elsewhere and identify the forces at work.
The solution is not just "do only what's needed by the customer".
There are emerging environments where the conditions don't force previously-rational decisions, and where assumptions no longer apply. New tools in the battlefields of yore, new beliefs and practices in cultures...
The stunning march of compute hardware in the last 50 years has changed many such conditions.
Those who work with new freedom - liberated from the strictures of old gods, able to harm enemies without putting themselves at risk, with the time freed from foraging to build - have to identify the new constraints and conditions at work.
And sometimes to make the conditions that make for sanity: Solon got ancient Greece out of a stagnating pickle by getting the wealthy to release the poor from debtors' jails but sign them up for the military that could defend lands and trade routes, if they subjected themselves to land-owner self-government and the annual ostracism of one person who went too far.
Capitalism used competitive markets to liberate but discipline business, but right now the scaling power of compute leads to winner-take-all, and the openness of the West is seeding closed systems (military or foreign) with the power to destroy the liberal governance that sustains it. In software we're stuck between Scylla and Charybdis: an Anthropic+OpenAI duopoly or Chinese control over the lifeblood of enterprise.
If there were someone who in the large had structured the freedom of software to make its practitioners and stakeholders sane, they'd be a good candidate to steer us through this situation, so this freedom wouldn't drive us insane.
It is not the software, it is the internet. Something Awful already had it figured out: The internet makes you stupid.
And they even figured that out before Cambridge Analytica happened.
Beautifully written post and true on many levels. The art of software stopped being an art once large amounts of capital started creeping in. There are no signs that we're returning to sanity any time soon.
As a founder of a few software startups, I agree with this. If I can give advice to other founders, remember than software is usually a means to an end, and for most users, they just want the bare bone essentials to work and work well. Everything else is nice-to-have-fluff that won't drive 99% of sales.
The apps I pay for are simple and focus on a super basic interface. BookFusion and Libro.fm are great examples.
It’s interesting because my experience is inverse (b2b software) - the bloated shiny solution what actually doesnt work at all performs better in the market than the sober, unsexy solution that just works.
Companies like Oracle or Microsoft are so massive not because they sell simple and focused products that work well; quite the opposite
Might be different when you’re selling to endusers
Oracle (and SAP and IBM) are not in the business of building software, they are in the business of never complete software, instead stretch the project as far as you can and bill to death.
The insanity the author is describing sounds like normal corporate BS to me. Everybody wants to "raise concerns," everybody is looking for an idea to take credit for, everybody has a reason your idea won't succeed. I'm pretty sure this is the same whether you're making software or advertising campaigns or plastic cups.
I once tried to explain a pointless debate over the definitions of "acceptance testing" versus "regression testing" to a non-tech person, and they said that was the most relatable thing I'd ever told them about my job.
windows adbloat and 15 corporate software policies and scanners drive people insane
I’ve always thought that this principle explains all sorts of cultural phenomena, from the tech industry having a poorer work-balance compared to others (the pace of development is only limited by how many hours you must sleep!) and programmers seemingly having worse engineer’s disease than in other disciplines (if software can do anything and know everything, how could we, the lever-makers, be any less than our creations?).