5 ms·

Honestly this article misses my main request as a user: 1. Software should be free of bugs. At the very least, updates should not introduce new bugs. 2. Softw

Honestly this article misses my main request as a user: 1. Software should be free of bugs. At the very least, updates should not introduce new bugs. 2. Software shouldn't phone home. Ever. If I want to submit a bug report I will submit one through the usual OS channels, and I will give my feedback through your feedback button. 3. If you are a web service don't ever popup banners/tips/chat windows/whatever. Put links to them and I will click on them if I want. If you pop up a modal asking for my e-mail address I am leaving immediately. 4. Assuming you are doing well on #1, you shouldn't need to release updates on an hourly cadence. If there is a security vulnerability release a fix ASAP, but for new features bundle them together and release annually for mature software or quarterly/semiannually for software that is still being finished. I mean having a color scheme that is pleasant to look at is nice, but I would rather you just use my system settings in the first place. What I care about is stability and that the software puts my interests, as a user, first.

paulryanrogers 7y ago
> 1. Software should be free of bugs. At the very least, updates should not introduce new bugs. This is the ideal, especially since it could make software usable indefinitely. Sadly platforms change out from underneath apps, even apps carefully written to use only officially sanctioned APIs. And even Microsoft's years-long efforts at backward compatibility have failed to keep many apps running. I don't think it's possible without walking back the rolling releases in favor of discrete, infrequent upgrades--at least as a long-term support option.
- derekp7 7y ago
  Breakage due to OS upgrades is one thing. But at least make sure that the software doesn't do anything obviously bad. For example, I was dealing with a "security product" (basically something that profiles activity on the OS looking for malware activity) that we were required to roll out, and come to find out it reliably corrupts the RPM package database on both CentOS 7 and Amazon AWS Linux 2, whenever the OS is rebooted (assuming the software is set to start on boot). Things like this are unacceptable.
  - lonelappde 7y ago
    Enterprise software is a different beast, since the users are not the purchasers and not consenting to use, and so their concerns don't matter.
hnick 7y ago
Corollary for #3 on desktop: Don't steal focus! Windows is egregious for this, I'll be typing away and a window pops up and I hit a key and now I've just cancelled something that was running the the background and was ready for the next step :(
- brigandish 7y ago
  OS X/macOS isn't much better. If I wrote my own GUI window manager I wonder if I'd even put in modal dialogs and the like. The ones that don't respond to keyboard presses and remain on top are the worst.
- yjftsjthsd-h 7y ago
  You know, this was one of the things that made me feel that I made the right choice in moving to Linux, years ago: I realized that focus was under my control. My current WM even has an option to disable focus stealing, but it's not necessary because the software defaults to respecting you. That, and I realized that all windows could be resized, regardless of whether it even made sense (Ever seen an okay/cancel dialog maximized? It's hilarious.). The system put the user in control. So I stayed:)
- tonyedgecombe 7y ago
  It's actually quite difficult to popup a Window in the foreground. Usually the taskbar icon indicates it wants focus but focus stays where it was. It was a long time since I looked but I think there was a registry setting to override this but it's quite rare to see that done.
EpicEng 7y ago
I don't feel this list is very reasonable. At least, it's far too dogmatic. 1. Yeah right. I assume you write software for a living; I'm not sure how you got through writing that sentence. 2. I agree that this should be 100% opt in. I'm fine with an initial prompt asking me for anonymous usage data, then get out of my face. Obviously there are reasonable exceptions for some types of software, but in general, agreed. How do you feel about license checking though? It's trivially easy to rip off software with no server side management. 3. Meh. No one would ever click them. They're annoying, but I've handed my email (with a +<company> appended) over to certain companies for certain coupons. I think a banner is fine. 4. Yearly? I enjoy getting small updates frequently for many types of apps. Being able to iterate on specific features can be good for both sides, and large releases put a big burden on the dev org. Like most things, it depends. Some software should remain stable for a good amount of time, but if e.g. slack wants to make minor changes every few weeks that are mostly transparent I really don't care (the WYSIWYG debacle is really a management failure.) Also, #1 is unreasonable. There _will_ be bugs, and now you're proposing they be accumulated for a year before release. I worked on medical device software for more than a decade and we had a release schedule shorter than a year.
- tstrimple 7y ago
  > 1. Yeah right. I assume you write software for a living; I'm not sure how you got through writing that sentence. Not the author, but I took this statement to mean no major bugs which actually prevent utilization of the core system. Not necessarily no bugs that aren't fringe or easy to work around or cosmetic only. If the app in question is an alarm clock, the thing better alert me on time every time. Bugs that interfere with that core function are unacceptable. But if the font of the clock is off for one second every midnight, it wouldn't rise to that level. I imagine that threshold varies from person to person.
  - EpicEng 7y ago
    That seems like a pretty generous interpretation of >Software should be free of bugs. At the very least, updates should not introduce new bugs. But sure, who wouldn't agree with you? Who doesn't strive for that? Bugs happen, even big ones, to the best of us. If the clause > Thou shall not push any major bugs appeared in your employment contract, would you sign it?
avree 7y ago
I mean, any API call to an external server can be considered "phoning home". What is your specific definition? I think submitting bug reports only through official channels is pretty lame. Most of the 'official channels' don't really provide much meaningful info to developers, there's limited support for custom debug/logging/etc. So your point 1 and point 2 are basically at odds.
enraged_camel 7y ago
Disagree very, _very_ strongly on number 4. I love — love — weekly/biweekly/monthly release schedules with any software I use. As a user, it gives me the impression that the software is being actively worked on, and to me that's very important. I don't care if the updates are minor, to the point of simply fixing typos. I like them, and want them frequently. I can also speak from the perspective of a developer. If you develop a new feature, why the hell would you wait for weeks/months to bundle it with other stuff, when you can release it whenever it's done and have your users start reaping its benefits right away? That way, they can also start giving you feedback much faster. This is why I love web browsers - honestly, every time a new Chrome/Firefox build is released, I update right away, and I read the release notes as well. In contrast, we use some enterprise software at work, and it comes out with a new version once a year, full of new features and bug fixes. I hate that. I hate that I have to wait for up to a year or more to get my hands on features I could have gained value from much sooner if the developers were on top of their game. I'm not saying you should release new features without testing and documenting them thoroughly. But the whole "bundling" approach is terribly wrong and misguided in my opinion.
- _jal 7y ago
  I understand the feeling, and used to share it more before I became a bitter old man with corporate responsibilities and a hatred of all spontaneity and joy. But constant changes can be a hassle for a lot of reasons. One pretty recent example from our shop was that a third-party service change combined with some vague wording in one of our "start here" docs for new hires led to subtly broken development environments. More often, the changes just randomly make documentation somewhere between difficult-to-interpret and nonsensical. It also increases the cognitive load for less-frequent users. This has caused me to switch tools out of frustration. ("I'm already relearning this part of my workflow, may as well try something else and see if it sucks less...") And that's before we get to new bugs, locally-inopportune deprecations, broken integrations, forced on-the-fly workflow modifications and all the other negative externalities of change. The nicest way to avoid this is to not surprise people - let folks opt in to/roll out changes on their schedule. (With reasonable deadlines, of course, whatever that means in context.)
- osamagirl69 7y ago
solidasparagus 7y ago
> Software should be free of bugs. Software shouldn't phone home Pick one. If you can't collect data, it is expensive to identify and fix bugs.
- osamagirl69 7y ago
  I specifically said no phoning home _without asking_. It is fine to have an automated process to submit bug reports if you feel your software is so buggy that it needs it. Any competent OS will also have an automated method for submitting crash reports back to the maintainers (ex, apport) That said, I would much rather that your software just doesn't crash in the wild. Ship less often. Either test internally or do a developer preview/nightly build if you need to crowdsource the quality control. Take some pride in shipping software that is good!
chrismcb 7y ago
None of these are going to happen. We all want but free software, but that is impossible . not is a goal we all strive for though. While you may not want ET to phone home, most other people do. For a variety of reasons. Upgrade checks, analytics, etc. As much as I hate ads, links will never cut it.
tonyedgecombe 7y ago
>At the very least, updates should not introduce new bugs I'm sure my software has plenty of bugs, the trouble is I don't know where they are. What I do have is a no known bugs policy. When I or a customer find a bug then that is a higher priority than adding new features.
fdsfdsfdsfds 7y ago
>4. Assuming you are doing well on #1, you shouldn't need to release updates on an hourly cadence. If there is a security vulnerability release a fix ASAP, but for new features bundle them together and release annually for mature software or quarterly/semiannually for software that is still being finished. it sounds weird So, basically you're writting feature X, then you have no feedback on it for e.g 3? 6? 10? months? you can ship ready & internally tested features with bug fixes.
sethammons 7y ago
> release annually Stop what you are doing and read either (or both) The Phoenix Project or The DevOps Handbook. TL;DR: smaller, more frequent deploys are safer, less likely to introduce bugs, provides faster feedback for better learning, and require built in automated testing, quality checks, and solid telemetry. It makes lives better for developers, qa, ops, product, the company, and customers. This is not "not move fast and break things."

paulryanrogers 7y ago

> 1. Software should be free of bugs. At the very least, updates should not introduce new bugs. This is the ideal, especially since it could make software usable indefinitely. Sadly platforms change out from underneath apps, even apps carefully written to use only officially sanctioned APIs. And even Microsoft's years-long efforts at backward compatibility have failed to keep many apps running. I don't think it's possible without walking back the rolling releases in favor of discrete, infrequent upgrades--at least as a long-term support option.

derekp7 7y ago
Breakage due to OS upgrades is one thing. But at least make sure that the software doesn't do anything obviously bad. For example, I was dealing with a "security product" (basically something that profiles activity on the OS looking for malware activity) that we were required to roll out, and come to find out it reliably corrupts the RPM package database on both CentOS 7 and Amazon AWS Linux 2, whenever the OS is rebooted (assuming the software is set to start on boot). Things like this are unacceptable.
- lonelappde 7y ago
  Enterprise software is a different beast, since the users are not the purchasers and not consenting to use, and so their concerns don't matter.

hnick 7y ago

Corollary for #3 on desktop: Don't steal focus! Windows is egregious for this, I'll be typing away and a window pops up and I hit a key and now I've just cancelled something that was running the the background and was ready for the next step :(

brigandish 7y ago
OS X/macOS isn't much better. If I wrote my own GUI window manager I wonder if I'd even put in modal dialogs and the like. The ones that don't respond to keyboard presses and remain on top are the worst.
yjftsjthsd-h 7y ago
You know, this was one of the things that made me feel that I made the right choice in moving to Linux, years ago: I realized that focus was under my control. My current WM even has an option to disable focus stealing, but it's not necessary because the software defaults to respecting you. That, and I realized that all windows could be resized, regardless of whether it even made sense (Ever seen an okay/cancel dialog maximized? It's hilarious.). The system put the user in control. So I stayed:)
tonyedgecombe 7y ago
It's actually quite difficult to popup a Window in the foreground. Usually the taskbar icon indicates it wants focus but focus stays where it was. It was a long time since I looked but I think there was a registry setting to override this but it's quite rare to see that done.

EpicEng 7y ago

I don't feel this list is very reasonable. At least, it's far too dogmatic. 1. Yeah right. I assume you write software for a living; I'm not sure how you got through writing that sentence. 2. I agree that this should be 100% opt in. I'm fine with an initial prompt asking me for anonymous usage data, then get out of my face. Obviously there are reasonable exceptions for some types of software, but in general, agreed. How do you feel about license checking though? It's trivially easy to rip off software with no server side management. 3. Meh. No one would ever click them. They're annoying, but I've handed my email (with a +<company> appended) over to certain companies for certain coupons. I think a banner is fine. 4. Yearly? I enjoy getting small updates frequently for many types of apps. Being able to iterate on specific features can be good for both sides, and large releases put a big burden on the dev org. Like most things, it depends. Some software should remain stable for a good amount of time, but if e.g. slack wants to make minor changes every few weeks that are mostly transparent I really don't care (the WYSIWYG debacle is really a management failure.) Also, #1 is unreasonable. There _will_ be bugs, and now you're proposing they be accumulated for a year before release. I worked on medical device software for more than a decade and we had a release schedule shorter than a year.

tstrimple 7y ago
> 1. Yeah right. I assume you write software for a living; I'm not sure how you got through writing that sentence. Not the author, but I took this statement to mean no major bugs which actually prevent utilization of the core system. Not necessarily no bugs that aren't fringe or easy to work around or cosmetic only. If the app in question is an alarm clock, the thing better alert me on time every time. Bugs that interfere with that core function are unacceptable. But if the font of the clock is off for one second every midnight, it wouldn't rise to that level. I imagine that threshold varies from person to person.
- EpicEng 7y ago
  That seems like a pretty generous interpretation of >Software should be free of bugs. At the very least, updates should not introduce new bugs. But sure, who wouldn't agree with you? Who doesn't strive for that? Bugs happen, even big ones, to the best of us. If the clause > Thou shall not push any major bugs appeared in your employment contract, would you sign it?

avree 7y ago

I mean, any API call to an external server can be considered "phoning home". What is your specific definition? I think submitting bug reports only through official channels is pretty lame. Most of the 'official channels' don't really provide much meaningful info to developers, there's limited support for custom debug/logging/etc. So your point 1 and point 2 are basically at odds.

enraged_camel 7y ago

Disagree very, _very_ strongly on number 4. I love — love — weekly/biweekly/monthly release schedules with any software I use. As a user, it gives me the impression that the software is being actively worked on, and to me that's very important. I don't care if the updates are minor, to the point of simply fixing typos. I like them, and want them frequently. I can also speak from the perspective of a developer. If you develop a new feature, why the hell would you wait for weeks/months to bundle it with other stuff, when you can release it whenever it's done and have your users start reaping its benefits right away? That way, they can also start giving you feedback much faster. This is why I love web browsers - honestly, every time a new Chrome/Firefox build is released, I update right away, and I read the release notes as well. In contrast, we use some enterprise software at work, and it comes out with a new version once a year, full of new features and bug fixes. I hate that. I hate that I have to wait for up to a year or more to get my hands on features I could have gained value from much sooner if the developers were on top of their game. I'm not saying you should release new features without testing and documenting them thoroughly. But the whole "bundling" approach is terribly wrong and misguided in my opinion.

_jal 7y ago
I understand the feeling, and used to share it more before I became a bitter old man with corporate responsibilities and a hatred of all spontaneity and joy. But constant changes can be a hassle for a lot of reasons. One pretty recent example from our shop was that a third-party service change combined with some vague wording in one of our "start here" docs for new hires led to subtly broken development environments. More often, the changes just randomly make documentation somewhere between difficult-to-interpret and nonsensical. It also increases the cognitive load for less-frequent users. This has caused me to switch tools out of frustration. ("I'm already relearning this part of my workflow, may as well try something else and see if it sucks less...") And that's before we get to new bugs, locally-inopportune deprecations, broken integrations, forced on-the-fly workflow modifications and all the other negative externalities of change. The nicest way to avoid this is to not surprise people - let folks opt in to/roll out changes on their schedule. (With reasonable deadlines, of course, whatever that means in context.)
osamagirl69 7y ago

solidasparagus 7y ago

> Software should be free of bugs. Software shouldn't phone home Pick one. If you can't collect data, it is expensive to identify and fix bugs.

osamagirl69 7y ago
I specifically said no phoning home _without asking_. It is fine to have an automated process to submit bug reports if you feel your software is so buggy that it needs it. Any competent OS will also have an automated method for submitting crash reports back to the maintainers (ex, apport) That said, I would much rather that your software just doesn't crash in the wild. Ship less often. Either test internally or do a developer preview/nightly build if you need to crowdsource the quality control. Take some pride in shipping software that is good!

chrismcb 7y ago

None of these are going to happen. We all want but free software, but that is impossible . not is a goal we all strive for though. While you may not want ET to phone home, most other people do. For a variety of reasons. Upgrade checks, analytics, etc. As much as I hate ads, links will never cut it.

tonyedgecombe 7y ago

>At the very least, updates should not introduce new bugs I'm sure my software has plenty of bugs, the trouble is I don't know where they are. What I do have is a no known bugs policy. When I or a customer find a bug then that is a higher priority than adding new features.

fdsfdsfdsfds 7y ago

>4. Assuming you are doing well on #1, you shouldn't need to release updates on an hourly cadence. If there is a security vulnerability release a fix ASAP, but for new features bundle them together and release annually for mature software or quarterly/semiannually for software that is still being finished. it sounds weird So, basically you're writting feature X, then you have no feedback on it for e.g 3? 6? 10? months? you can ship ready & internally tested features with bug fixes.

sethammons 7y ago

> release annually Stop what you are doing and read either (or both) The Phoenix Project or The DevOps Handbook. TL;DR: smaller, more frequent deploys are safer, less likely to introduce bugs, provides faster feedback for better learning, and require built in automated testing, quality checks, and solid telemetry. It makes lives better for developers, qa, ops, product, the company, and customers. This is not "not move fast and break things."