Earlier quoted context omitted.
I wonder how many of these feature requests are because the client does not understand how the software should be used? It could be that it is not designed to solve there problem, and having purchased it they are trying to get some utility from it. Would not be the first time that had been forced to use a system that was not suitable.
This just shows how ass-backwards the whole industry is with its "standard practices", a lot of which I see repeated as advice in the thread. It goes like this: 1. Push a product (or these days, service) at people. Preferably a captive audience. In B2B, that may involve growing an "internal champion" at a customer company, preferably a manager that doesn't need the software themselves, that can be bamboozled by your…
When users never use the features they asked for
201–210 of 228 posts
Re: When users never use the features they asked for
#202Earlier quoted context omitted.
Yea, we were a consumer electronics company that mostly was subcontracted out to make components or complete hardware. I remember working on products for Denon, Crestron, Roku, Samsung, LG, Direct TV, Microsoft, HP, Nintendo, Sony and Audiovox (and their subsidiaries--Monster etc), and in Europe, One For All brand. It was honestly pretty exciting. Regarding web services, like I said, we had a library of these wavefor…
Ah, so I'd guess you were producing some chip that generated IR signals to control various consumer electronics devices, and the library is a library of control commands of thousands of devices of different manufacturers. Basically what you need to build a universal remote control, or a remote control for a specific device that includes controlling capabilities for other manufacturers' devices.
Re: When users never use the features they asked for
#203Earlier quoted context omitted.
Yeah I was definitely right to quit, my career has been pretty great since then. But I did get a lot out of the few years I worked there, even though a lot of it sucked. It was my first proper job and they’d basically let me work on anything I wanted to, even though I was incredibly green and was just figuring it all out as I went. I definitely fit a lot more experience and learning into those years than you’d reason…
I be also had a job early in my career where I was basically allowed to work on anything that interests me and 20 years later I’m still relying on that experience. Maybe this is something every junior should do - try a bit of everything and see what you like.
Plus, in my experience consulting companies are more focused in employee well-being as it's their only asset.
Re: When users never use the features they asked for
#204Earlier quoted context omitted.
One option is to implement a non-working version of the apparently unnecessary feature. In the unlikely event someone tries to use it, an exception is trapped, and the appearance is given that there's a bug inhibiting the feature use. A brief apology is issued. Then, and only then, does the development team actually implement the feature.
I would run from that product.
Re: When users never use the features they asked for
#205This happened to me so many times. Like when multiple users asked me to add monitor brightness dimming when the sky is covered with clouds in the Location Mode of my app for controlling monitors: Lunar ( https://lunar.fyi ) Turns out cloud cover reported by weather APIs isn't a good predictor of the ambient light. The feature was so useless (and expensive because weather APIs are not cheap) that it never made it into…
> expensive because weather APIs are not cheap Just FYI, you can get free hourly (or 30/15 minute, I forget) cloud coverage data from the likes of EUMETSAT (and equivalent US/asian agencies).
Since then I also found Open Meteo (https://open-meteo.com/en/docs) to be a nice alternative for smaller projects.
Re: When users never use the features they asked for
#206This is relevant perhaps 10% of the time. The other 90%, the devs have absolutely no idea how to actually perform the task the user of the software is trying to do, don't talk to customers, don't dogfood it, often don't even understand the industry, and the result is a horrible UI which forces people to severely adjust their existing processes to fit the software. Then if course the devs complain about "the stupid us…
Re: When users never use the features they asked for
#207Re: When users never use the features they asked for
#208Earlier quoted context omitted.
Ah, so I'd guess you were producing some chip that generated IR signals to control various consumer electronics devices, and the library is a library of control commands of thousands of devices of different manufacturers. Basically what you need to build a universal remote control, or a remote control for a specific device that includes controlling capabilities for other manufacturers' devices.
I think you hit the nail on the head with that.
If I had to take another guess, I would even nail it down on him having been employed by a company called Universal Electronics, which produced a series of universal remotes called "JP1 remotes" in hardware hacker circles (see for example http://www.hifi-remote.com/files/help/The%20WHAT%20and%20WHY...) and also acted as an OEM for a lot of other companies, so their tech could be found in various remotes of different brands.
[edit] I was slightly wrong. He was working for Zilog (which sold their universal remote business to Universal Electronics Inc. in 2009 however) and probably involved with a cool-named product called "Crimzon RC Blaster": https://www.zilog.com/docs/ir/PB0171.pdf
Re: When users never use the features they asked for
#209Earlier 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…
On the topic of lost source code... we had a few blessed binaries that were vital to building System 8 and System 9 at Apple. There was a single build machine that could generate these binaries from other object code but the source was long gone. Oh please oh please old Quadra 700, don't give out on us! Those days are over right? Surely nothing like that is happening with OSX...
Re: When users never use the features they asked for
#210Earlier quoted context omitted.
One option is to implement a non-working version of the apparently unnecessary feature. In the unlikely event someone tries to use it, an exception is trapped, and the appearance is given that there's a bug inhibiting the feature use. A brief apology is issued. Then, and only then, does the development team actually implement the feature.
A quick way to teach users never to click that button again, I'd say.