There is also the corollary that if you have a feature that no one uses then make sure it works before deciding that your users don't like it. A feature can be awesome in its desired form but if it's janky as hell or unreliable then it won't get used. If the implementation sucks it's not proof that the feature sucks.
The contrapositive would then be that if you find some really janky/unreliable feature that people are using, it must be pretty important to them and you should tread lightly when modifying it.
True. I should have specified that the volume of use for poorly implemented features is only not useful for determining that it is a bad feature. Lots of use indicates that it may be a great feature, or that it's not the feature you thought it was (https://xkcd.com/1172/)
Rather bizarre logic regarding unit tests. Surely the correct thing to do is to add telemetry to the application to get metrics on feature usage.
Of course this may not be practical for small utilities, like ls in the example. By the way ls -p (well, -F actually) was quite useful in the time before coloured output. I remember it being turned on by default on some systems I used way back when.
> Lots of large applications have extensive telemetry without any significant blowback (as far as I'm aware). MS Office, Firefox, Chrome, ...
Not sure about the others, but AFAIK Firefox telemetry is only enabled (or at least sent to Mozilla) on pre-release channels.
> It's not undoable for utilities either
It's undoable in the sense that you'll be bundling more telemetry code than there is actual utility code, and downstream is going to remove it as soon as it lands.
Firefox Health Report is on and shared with Mozilla by default on release builds - it prompts you about it on first run. There's additional telemetry in pre-release builds.
ls -p and -F are still useful. Removing -p and -F is similar to removing 3d widgets from user interfaces and then wondering why users don't know what is an interactive ui element in modern UIs (which happen to look like Windows 1.0). I won't understand the desire to shuffle things around just to make things seem fresh, mostly user interfaces but other things too. Emacs is a good example what stable interfaces can get you. Users have been carrying around their ~/.emacs.d for 30 years and it's working on their Raspberry Pi just like it did on HPUX.
Before colors, "ls -F" was often used. I have only seen "ls -p" in scripts. I think the command "du -ch `ls -p| grep -v '/'`|tail -1" is a typical use case.
Surely the correct thing to do is to add telemetry to the application to get metrics on feature usage.
And when the popularity of feature X happens to correlate with people running in environments that don't let the tool phone home through their default-deny traffic filters?
Fuck them and their use case for not letting you monitor ever little thing?
Maybe they could bake a warning about the use of deprecated features into the default MOTD or some other system alert?
Something like: "Hey, we are considering deprecating 'ls -P' and detected its use by your system. We'd love to work with you to ensure a smooth transition, check out 'man depwarn3754' for details on how you can help." The man page could include a notice about why they want to deprecate it, how you can get away from using it, and, how to contact them if you think it's an issue.
I remember hearing about some feature being removed from OpenSSL not long ago after it was discovered that it couldn't have been used because... it didn't actually compile(?), if memory serves. Sorry, I don't remember all the details at the moment (it's almost 7am and I've been awake for ~36 hours).
I'm assuming that's what this is about but maybe not.
Depends. You want only the contents of a directory when you ls it. Many scripts and programs depend on determinable output from utilities like ls, find, ps, etc.
Very true. You could also add a suppression flag to keep scripts running. I think I'd rather have a script die from a deprecation notice than the feature being removed.
Tests prevent you from accidentally breaking features. If you want to deliberately break a feature to see whether anyone uses it, you can still do that. Surely it's better for this to be a conscious decision rather than random accident.
This is a weird one, but it seems the point isn't "Broken features aren't used" but rather "unused features don't get maintained and tend to break" and also the point of the article isn't broken features but "on whether to remove features, and which ones to remove"
30 comments
[ 0.25 ms ] story [ 93.5 ms ] threadOf course this may not be practical for small utilities, like ls in the example. By the way ls -p (well, -F actually) was quite useful in the time before coloured output. I remember it being turned on by default on some systems I used way back when.
It's utterly undoable for utilities (small or not) even if you ignore the likely blowback à la W10 telemetry.
It's not undoable for utilities either, just the effort/benefit ratio probably doesn't justify it.
Not sure about the others, but AFAIK Firefox telemetry is only enabled (or at least sent to Mozilla) on pre-release channels.
> It's not undoable for utilities either
It's undoable in the sense that you'll be bundling more telemetry code than there is actual utility code, and downstream is going to remove it as soon as it lands.
And when the popularity of feature X happens to correlate with people running in environments that don't let the tool phone home through their default-deny traffic filters?
Fuck them and their use case for not letting you monitor ever little thing?
Something like: "Hey, we are considering deprecating 'ls -P' and detected its use by your system. We'd love to work with you to ensure a smooth transition, check out 'man depwarn3754' for details on how you can help." The man page could include a notice about why they want to deprecate it, how you can get away from using it, and, how to contact them if you think it's an issue.
It'd be a lot of leg work, that's for sure.
I'm assuming that's what this is about but maybe not.
I surely can't be the only one, and I'm surprised that the article's author suggested it's never used.