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

When users never use the features they asked for

web.eecs.utk.edu

Post reply on HN
Print view View original

91–100 of 228 posts

Re: When users never use the features they asked for

#91

Post by oceanghost »

oceanghost wrote: post #39

Before the launch of the XBOX 360, the company I worked for was one of their suppliers, and without going into enough detail to make me identifiable, the management of our two companies had arrived at sort of a stalemate: We didn't want to tell them exactly how our algorithms worked, and they didn't want to tell us exactly what they were doing with them-- think of it like a data compressor where, we don't want them t…

I can't edit my post anymore-- before someone realizes my mistake, it was the XBox One, not the 360. Rails barely existed at the time of the XBox 360 development.

Re: When users never use the features they asked for

#92

Post by c_o_n_v_e_x »

"When users never user the features they asked for..."

At least they are users asking for a feature. I've lost count the number of times where a sales guy swears up and down that he'll close the deal if we put features X, Y, and Z. The C-Suite gets hot and bothered about closing and I get overruled. Stories for X, Y, and Z get written, backlogs reprioritized, features developed. Ta da! Then what happens?

"Customer" goes dark and we never hear from them again. ::laughcry::

Re: When users never use the features they asked for

#93

Post by AmericanChopper »

pram wrote: post #78
AmericanChopper wrote: post #44

Earlier quoted context omitted.

The worst programming experience of my life related to lost source code. I was working for a place that had a service running from a Java app that was customized for each customer, about 200 copies of roughly the same app. There was source control at some point, and when a new customer was being on boarded they’d just make the customizations they required, compile the app, and deploy it. By the time I worked there (y…

Hilarious. Why didn't you refactor the customizations into a config file, and just deploy a single jar though? If you went through the effort of rewriting the entire thing!

The issue I found when I was first looking at it was they were all a little bit different in random, and confounding ways. Also, whatever the “base version” of the application was had been undergoing development over the years when all these forks were being made.

Looking back on it, that likely would have been the best approach. But at the time the complexity of designing something like that was a bit beyond me.

Re: When users never use the features they asked for

#94

Post by amatecha »

rkagerer wrote: post #77
olivierlacan wrote: post #58

Earlier quoted context omitted.

This is why changelogs and release notes are not optional or tucked away in a dark corner. And users who request features need to be notified (actively, specifically) that something they requested or a bug they hit was resolved or addressed. I know, that's a lot of work. But what's the point of fixing things if you never tell someone it's fixed.

That's great advice, but it's untrue that nobody reads changelogs. I read them religiously for software I'm passionate about as a user, and when I solo'd a product for a decade I was regularly surprised how familiar some of my customers were with mine (most often when they had dedicated IT resources or were similarly small boutique outfits themselves). I've also managed large, custom enterprise projects where subject…

I've started collecting screenshots of app updates that are simply "bug fixes and performance improvements" because it's such a joke at this point. What bugs? How much performance improvement? Did you also nuke one of my favorite features while you were at it, or require other actions of me that I wasn't intending to perform? Who knows? Guess I'll roll the dice once again...

Re: When users never use the features they asked for

#95

Post by makeitdouble »

zw123456 wrote: post #81

“Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on th…

This flies pretty opposite to what the lessons the author got from their experience ("Keep your users in the loop, always. Do not go build in isolation.", "If you make assumptions about your users, they will find a way to surprise you.")

I kind of feel your view is a variation on "if you built it they will come", which is true in some cases, and will wield spectacular failures in ton of other cases.

Re: When users never use the features they asked for

#96

Post by makeitdouble »

b0afc375b5 wrote: post #82
protomyth wrote: post #41

The funner one is unique to enterprise developers. Begged to implement a feature to the enterprise software, the development team puts in a hell of a lot of hours to get this time sensitive feature into the production. Then, out of nowhere, a manager of some import informs everyone that they cannot use that feature as its "against best practices" or some other language to that effect. Bonus points if said manager was…

What do you do at this point? People complain about meetings saying that "this could have been an email" (including me). But I believe some people just don't read email/chat/jira comments. Maybe they're busy or just don't care at all, who knows. How else would you get your point across?

I think people don't really follow meetings either. We had a ton of going back to the transcripts to prove topics have been discussed.

There is no magic bullet, if someone has the power to make decisions, you are always at the risk of having them change course at any point in time. The only think you can do is deeply convince them it's in their interest you succeed.

Re: When users never use the features they asked for

#97

Post by pull_my_finger »

amatecha wrote: post #94
rkagerer wrote: post #77

Earlier quoted context omitted.

That's great advice, but it's untrue that nobody reads changelogs. I read them religiously for software I'm passionate about as a user, and when I solo'd a product for a decade I was regularly surprised how familiar some of my customers were with mine (most often when they had dedicated IT resources or were similarly small boutique outfits themselves). I've also managed large, custom enterprise projects where subject…

I've started collecting screenshots of app updates that are simply "bug fixes and performance improvements" because it's such a joke at this point. What bugs? How much performance improvement? Did you also nuke one of my favorite features while you were at it, or require other actions of me that I wasn't intending to perform? Who knows? Guess I'll roll the dice once again...

When I read release notes like that I immediately assume malice. I don't believe that the information is not available or that the devs are too lazy to bullet point _at least_ the major changes or vulnerabilities fixed. I think this is generally an excuse to slip in tracking/etc without resistance.

Re: When users never use the features they asked for

#99

Post by matheusmoreira »

kerblang wrote: post #9

One of many things I learned from writing software just for myself is that I'm just about as bad as anybody at figuring out what I really want, even when I'm talking to myself. I've even had one or two cases where I ignored a feature I asked myself for, and much later realized: Hey, I could actually use that. The worst is asking myself, "How many times do I have to ask for this before you quit procrastinating and jus…

Sometimes it's wise to ignore what you want. So many times I started a project only to end up with 3 libraries and a custom build system. It's like I can't help myself. It got to the point I was too embarrassed to publish these things on GitHub.

Re: When users never use the features they asked for

#100

Post by thrashh »

unholiness wrote: post #79
david_allison wrote: post #4

Great article, but I disagree with the premise. Code review is too late for most automated analysis (at the level of: "parameter isn't validated" as seen in the screenshot), it should ideally be done as a compiler/lint check in the IDE, and at worst as a git pre-commit hook. In most cases it's not worth sending a code review if there is automated feedback which can and should be addressed before a human sees it. It s…

One automated thing I've been really wanting to add to our code review process is copied code detection, where a piece of code is very similar to code somewhere else in the product (though likely not part of the current review). Obviously there's cases where this is code smell, but plenty of times it isn't. It's not something that you would want to block shipping. But if you do want to ship code like this, you should…

It’s not automated but IntelliJ does this.
Post reply on HN