Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I have a theory that software drives people insane

graybeard.ing

Post reply on HN
Print view View original

91–100 of 206 posts

Re: I have a theory that software drives people insane

#91

Post by Sleaker »

stinos wrote: post #76
bob1029 wrote: 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…

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…

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?!

Re: I have a theory that software drives people insane

#92

Post by ronjakoi »

mjr00 wrote: post #43
anonymars wrote: post #36

Earlier quoted context omitted.

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?

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

I don't like that they have that data in the first place. But then again I don't use Chrome.

Re: I have a theory that software drives people insane

#93

Post by ronjakoi »

Brian_K_White wrote: post #30
jghn wrote: 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…

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.

Re: I have a theory that software drives people insane

#98

Post by sph »

anthonypasq wrote: post #73
hliyan wrote: post #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…

the average developer back then was much better. 50% of engineers in the average IT department produce zero or negative value. I worked at one of the largest financial institutions in the world and had coworkers that literally committed zero code for months.

I don't think it's because of the 'average developer', but because system's like OP's were designed by experienced engineers, while the modern toolchain is written by "senior developers" with 3 years of experience. They have a lot of energy to pull all-nighters reinventing yet another wheel, and not the wisdom to avoid doing that, or to do it in a sensible way.

In fact, the entire tech sector, favouring fresh grads out of college over greybeards, is built this way. My pet very controversial theory is that this phenomenon is massively fueled by everybody and their dog using ADHD stimulant medication to get through their day; fresh grads + amphetamines is the preceding step to Kubernetes and the entire React ecosystem.

tl;dr: modern software is built by 'work hard, not smart' kinda types.

Re: I have a theory that software drives people insane

#100

Post by asdfman123 »

burningChrome wrote: post #47
cosmic_cheese wrote: post #10

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…

>> I think that over-reliance on analytics has had a similar effect I lost track of how many times the directors would tell us, "Since the analytics say A, we should do B." then the research person says, "Sure Jim, great idea, lets get a few rounds of useability research and confirm it first." Then the always predictable thing happens: Users never align with your analytics. Seeing data and seeing someone struggling t…

My problem is I can skip all those steps and 8 separate meetings by applying a little common sense to software design.

Unfortunately, orgs often treat devs like this as indulgent or wasting time. They need it to be done the inefficient way because that's the only way they have visibility and control.

Post reply on HN