Live data from Hacker News

I have a theory that software drives people insane

graybeard.ing

31–40 of 206 posts

Re: I have a theory that software drives people insane

#31
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.

Re: I have a theory that software drives people insane

#32
post #9

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

Re: I have a theory that software drives people insane

#33
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.

Re: I have a theory that software drives people insane

#34
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.

Re: I have a theory that software drives people insane

#35
post #19
post #4

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…

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.

Re: I have a theory that software drives people insane

#36
post #4

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…

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…

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?

Re: I have a theory that software drives people insane

#37
post #9

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.

Re: I have a theory that software drives people insane

#38
post #19

Earlier quoted context omitted.

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.

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 univer…

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...

Re: I have a theory that software drives people insane

#39
post #4

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…

[dead]

Re: I have a theory that software drives people insane

#40

Earlier quoted context omitted.

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…

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?

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!
Post reply on HN