“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 the page.”
When users never use the features they asked for
81–90 of 228 posts
Re: When users never use the features they asked for
#82The 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?
Re: When users never use the features they asked for
#83You know what's worse? When you have no metrics and have NO IDEA whether users are actually using the features you ask for.
I realized this a while back due to the fact we had a feature on customer request, which was in release for some time. It had a bug in it, and nobody ever told us about it - which told us nobody ever used it.
And the only reason I know nobody used it is that we collect no metrics. And yea I'm working on that with the company...
Re: When users never use the features they asked for
#84"Don't underestimate engineering challenges that you only have an external view of."
I wish more people would heed this lesson, especially in HN comments.
Re: When users never use the features they asked for
#85People will buy products because if features they will never use. Not building costs money.
Case in point: 90% of the pickup trucks sold in the USA.
Re: When users never use the features they asked for
#86I once stayed at work for 36 hours straight to finish assembling a batch of circuit boards for a customer's prototype. I dropped them off at FedEx for next day AM shipping right before they closed on a Saturday and felt pretty good to just barely make the deadline!!
Well Monday morning, the customer assembles the first prototype and it lights on fire. Turns out there were lots of other problems and all my work was for nothing.
I learned a lot from the experience!
Re: When users never use the features they asked for
#87[deleted]
Re: When users never use the features they asked for
#88Earlier 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!
I think the OP is saying each program was slightly different. Like it had been forked 200 times.
Re: When users never use the features they asked for
#89Great 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…
Sonarqube has, among other things, code duplication detection, where it detects very similar, but slightly different blocks of code.
It's possible to wire things up so that it runs when you open a merge request and notifies you via email the results.
It's not a silver bullet though.
It also has a linter plugin for vscode (and possibly other editors) that DID NOT work well, atleast the last time I checked which was before February this year. Just thought you should know, incase you decided to just use the linter.
Re: When users never use the features they asked for
#90So I want to share a story about user asking for a feature then not using it. I run an email forwarding services( https://hanami.run ) basically you add your domains in and add some records. We had this one heavy users who has like hundreds of domains. So our UI isn't design for that. Who has hundreds of domains? So they approach and asked us for a way to organize those domains into a hierarchy structure. All good. T…
If I'm being honest, that sounds like a net win for you and your company. Even if they aren't still around, now you've got a better and more attractive interface!