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 on the email chain about the feature and its progress.
When users never use the features they asked for
41–50 of 228 posts
Re: When users never use the features they asked for
#42Before 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…
Cool story thanks for sharing - so how did they get around the issue for three years without the app?
Re: When users never use the features they asked for
#43Sometimes I wonder if software is becoming worse because logging is coming better. We have so much data about problems that users are having, feedback they're providing, etc. Perhaps following the mass of people is the root cause of software's constant and worse UI changes.
Jira takes the biscuit with their text editor. Always changing and hard to make sense of. Recently ctrl-enter and enter actions were swapped!
My favorite thing about their text editor is that it will delete all of your changes with no option for recovery if you accidentally hit the escape key. I also like how this has been an open issue for many years on Jira, but they refuse to change it for some reason (or at least that's the state of it the last I checked about a year ago. Thankfully, I don't have to use any Atlassian products anymore.)
Re: When users never use the features they asked for
#44Before 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…
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 (years later), all source code had been lost, and I was tasked with creating a CI/CD system that included managing these apps (they’d now decided they needed to be maintained).
For each one I had to decompile the whole thing, rewrite the code into a human readable format, redeploy and test it. They were filled with all sorts of horrible anti-patterns too, like hard coded file paths, and some of them were only used once a year (but for an absolutely business critical process).
About half way through we had a major data center failure that meant we had to do a failover, which of course broke most of these apps with all their hard coded configuration. So instead of having months to work through all of this garbage, I was asked to get them all working immediately.
I got them all working in 3 days, which I thought was quite a monumental accomplishment. But my CEO was very dissatisfied that it took so long. I quit a couple weeks later, and still almost regret putting so much effort in to saving them. A friend of mine still works there and apparently all of these applications are in exactly the same state as I left them.
Re: When users never use the features they asked for
#45A fine post and I'm sure a fine tool, but why is an internal linter tool the subject of a proper academic paper? I can't imagine writing an academic paper for any of the projects of similar complexity and general interest that I've worked on.
You should consider it then! Having concrete data about anything in a peer reviewed form is always valuable.
Re: When users never use the features they asked for
#46Earlier quoted context omitted.
How subtle was the update message letting the users know about the new feature?
Yeah sounds like the lesson here is that nobody reads the update messages.
If quantum scientists thought the slit experiment was exciting, they should study IT user preferences and be amazed how depending on the mode of communication/observation, customers will both scrutinize every letter you write while simultaneously not reading it at all, will know every wrong pixel of your UI but not know where the button for "Thing" (labeled "Thing") is, and how anything you make is somehow the best worst average thing they've ever seen.
If you're ever user facing it's a harsh but quick lesson that you can't really count on any users to follow any real pattern. Different persons latch onto different things, with adamant proponents and opponents of everything with a huge swatch of grey shades in-between. At a certain point you just need to decide when the "grey" is no longer grey for you on a particular subject and start to optimize for the part that cares while checking why the grey part isn't as interested.
A lot of conversations with clients I have are with those in the grey territory, where they don't quite know what they want but they know they want it. Often times, they're more looking for a reference architecture and something to compare their current processes/workflows to, and this usually is pretty simple to work with. Those that are proponents of a feature N are typically vocal and picky, but the feedback tends to be pretty good and the guidance is clear on how they envision it, since there's a clear workflow on their side a lot of times that they want to optimize. Opponents of feature N typically bring out the edge cases and demand a solution, and are equally, if not more vocal than the proponents.
It's really a tricky thing, and it's never really clear which is going to be "best" for users/the dev team.
Re: When users never use the features they asked for
#47Slightly frustrated to read this, because this is user research 101! It's really impressive when someone independently discovers practices from an outside discipline, just by observation and inference. However, somebody could have saved this poor guy a lot of frustration by not forcing him to develop a product design methodology from first principles.
Is there a book(s) you could recommend for product design methodology?
Re: When users never use the features they asked for
#48Before 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…
Cool story thanks for sharing - so how did they get around the issue for three years without the app?
Thank you!
If they were that serious about security-- the chips we made also implemented this same compression algorithm. It would have been trivial to hook one up to an arduino and feed it the data you wanted to encode. I assume someone realized this, or they never really had a need to encode their own data (we provided a extensive library of encoded data).
I strenuously disagreed with the business justification for keeping all this stuff secret. But it was my job to respect those decisions.
It was a lot of fun writing the (rails) app itself.
Re: When users never use the features they asked for
#49Re: When users never use the features they asked for
#50Earlier quoted context omitted.
Cool story thanks for sharing - so how did they get around the issue for three years without the app?
Thank you! If they were that serious about security-- the chips we made also implemented this same compression algorithm. It would have been trivial to hook one up to an arduino and feed it the data you wanted to encode. I assume someone realized this, or they never really had a need to encode their own data (we provided a extensive library of encoded data). I strenuously disagreed with the business justification for…
back when turbolinks were hot shit :D