Sometimes 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.
When users never use the features they asked for
31–40 of 228 posts
Re: When users never use the features they asked for
#32I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so…
The wonders of digital transformation.
One of my biggest insights here was that digital transformation is not only the technical upgrade or simplicity of implementation but rather the cultural implementation i.e., process re-development and re-training.
Re: When users never use the features they asked for
#33I once spent a week working on a fairly complex feature for a product that the users were demanding almost daily updates on. I delivered it and, by coincidence, happened to be where the users were a couple of weeks later and I stopped by to say hello and saw that the user who had been asking for the feature every day was still using the product the "old way". I asked why and he didn't seem to follow what I meant, so…
You did the customer success role.
Re: When users never use the features they asked for
#34Sometimes 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!
Re: When users never use the features they asked for
#35Earlier quoted context omitted.
Your comment is more true today than it was back then, not that I disagree with you posting it. Back then linters were a twinkle in the hopeful eye of software devs. Now they're battle hardened.
Back then was 2018. Lint dates from the seventies. I doubt it was the first static analysis tool, either.
You're right. I read 2008 in the post and thought the writer was talking about a time shortly after then. By the late 2010s linters were prevalent.
Re: When users never use the features they asked for
#36Great 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…
There's nothing more frustrating than a stupid machine telling me it knows better when it doesn't. I used to work on a team where the build defaulted to fail if something wasn't used and debugging was a fucking nightmare because the moment you comment out a block of code there's a cascade of warnings into errors that is just never ending (it was typescript so it leaked all the way back to module definition). I had to…
Had an issue like that. The workaround snippet that fixed it was aptly named stfu.js by the author.
Re: When users never use the features they asked for
#37Earlier 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.
Couldn't have anything to do with how app update screens share the exact ergonomics that subscribe-to-the-newsletter nags and other ad popups have.
Re: When users never use the features they asked for
#38> Turns out there were a few hiccups: everyone involved in that project we wanted to use had left the company, we had no idea how to build the source code, it had something like 500,000 lines of code, and the one person we found that knew anything about the project was 13 hours ahead and stopped replying to our emails.
When you don't talk to users this is what you end up with.
Re: When users never use the features they asked for
#39Before 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 to know the exact compression algo, and they don't want us to have their data.
So, somehow, It is arrived at that a website will be created that encodes MS's proprietary data, but doesn't store it, but also our algorithm is implemented server side, so there's no leakage of proprietary stuff.
A month later, the app is done and tested and I'm decoding data from the website on real hardware. I move on to the next project.
Three years later, the Xbox 360 is out, I decide I'm tired of filling out reimbursement forms for Heroku and its got to be a security risk with no updates in 3 years... so I take a look at the apps stats to see if its feasible to shut it down--exactly zero users. Nobody ever attempted to use it, not even once.
Ironically and unknown to me, the source code had been lost in a freak accident and when I deleted the Heroku account that was the only copy of the source left.
Even worse, a year later someone claimed to have a use for the app and where was it please? And I had to explain we no longer had the source. I remember a very long e-mail about how irresponsible we were.
Re: When users never use the features they asked for
#40Slightly 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.