5 ms·

Yes, that is the problem. That is why so much software sucks. Because the people who make it don’t use it, and hardly care to thoroughly test if it works. We

by sshine 2y ago

Yes, that is the problem. That is why so much software sucks. Because the people who make it don’t use it, and hardly care to thoroughly test if it works. We’re lucky to catch things with extensive dogfooding. (Also, no blame here. I could imagine working for Canonical and not even running Ubuntu.)

kyrofa 2y ago
> Also, no blame here. Oh don't worry, no offense taken. It's an interesting problem: dogfooding is definitely a good way to catch problems, but if your release is unstable enough to break machines, you can end up with a wide swath of the company being unproductive. The stability of the overall release wasn't one of my core responsibilities, so naturally I gave more priority to the things that were; I needed a release that worked so I could get my job done. There might be some cultural solutions to that. For example, if the company expects that employees are dogfooding, perhaps testing out a beta in a specific timeframe, it could be culturally expected that devs might have broken machines during that timeframe. If was that taken into account in both the schedule as well as support paths, that would make things a bit easier. Honestly, though, even if that were the case, it would still be a hard sell for me. Quite simply: I don't like failing at my duties. I would need to be convinced that this was one of my duties, and I'm not sure how the company would pull that off. And that's ignoring other very practical concerns, such as the fact that a fair number of Canonical engineers only have one work machine. Having that machine down, depending on the definition of "down," can make it difficult to get support in the first place.
- memebrane 2y ago
  Why wouldn't you just run your stable work on a vm? Drop it onto an unstable host to play around and of it breaks your work environment is backed up, stable, and unimpeded. There are many creative ways to work and dogfood.
  - kyrofa 2y ago
    Perhaps I'm misunderstanding your question, but is it really dogfooding if every meaningful thing I'm doing is within a stable VM? In general, a VM for my work doesn't change anything. It doesn't magically keep anything backed up: I still need to commit/push regularly, and so on. If the host explodes, I'm still down, even if what I'm doing is in a VM. I could immediately reinstall an older release and get set back up, but that isn't really dogfooding for an OS. I would need to report a bug and actually get the issue resolved, which generally means running in a broken state for a while to get there. Beyond that, I've used a VM for my day-to-day work in the past, and honestly I found it maddening. I couldn't fully utilize my computer without starving the host of resources, and there were a thousand other papercuts relating to hardware access and general instability. I try to avoid that development story these days. As you can see, my concerns here have nothing to do with losing code or data. They relate to lost productivity and not satisfying my primary duties.
    - sshine 2y ago
      > a VM for my work doesn't change anything For complex software, real-life testing all the corners is impossible. You'd get some value out of people running it on VMs, some people running it on the same old hardware, some people running it on cutting-edge hardware, some people running it for extended periods and doing dist-upgrades, some people constantly reinstalling it (even within a VM). There are so many places software could fail. Especially things that aren't repeated often seem to fail: For example, websites where logging in works, but creating a user fails and nobody notices, because all employees already have accounts.
      - kyrofa 2y ago
        I think you're misinterpreting my response. Of course there's value in testing operating systems within VMs. In fact, a solid chunk (if not most) of the Ubuntu install-base is VMs, believe it or not. I wasn't talking about that at all, but rather responding to the idea that, if I used a VM as my development platform, my problems would go away. In reality, in that context, it really changes nothing.
    - wink 2y ago

by sshine 2y ago

kyrofa 2y ago

> Also, no blame here. Oh don't worry, no offense taken. It's an interesting problem: dogfooding is definitely a good way to catch problems, but if your release is unstable enough to break machines, you can end up with a wide swath of the company being unproductive. The stability of the overall release wasn't one of my core responsibilities, so naturally I gave more priority to the things that were; I needed a release that worked so I could get my job done. There might be some cultural solutions to that. For example, if the company expects that employees are dogfooding, perhaps testing out a beta in a specific timeframe, it could be culturally expected that devs might have broken machines during that timeframe. If was that taken into account in both the schedule as well as support paths, that would make things a bit easier. Honestly, though, even if that were the case, it would still be a hard sell for me. Quite simply: I don't like failing at my duties. I would need to be convinced that this was one of my duties, and I'm not sure how the company would pull that off. And that's ignoring other very practical concerns, such as the fact that a fair number of Canonical engineers only have one work machine. Having that machine down, depending on the definition of "down," can make it difficult to get support in the first place.

memebrane 2y ago
Why wouldn't you just run your stable work on a vm? Drop it onto an unstable host to play around and of it breaks your work environment is backed up, stable, and unimpeded. There are many creative ways to work and dogfood.
- kyrofa 2y ago
  Perhaps I'm misunderstanding your question, but is it really dogfooding if every meaningful thing I'm doing is within a stable VM? In general, a VM for my work doesn't change anything. It doesn't magically keep anything backed up: I still need to commit/push regularly, and so on. If the host explodes, I'm still down, even if what I'm doing is in a VM. I could immediately reinstall an older release and get set back up, but that isn't really dogfooding for an OS. I would need to report a bug and actually get the issue resolved, which generally means running in a broken state for a while to get there. Beyond that, I've used a VM for my day-to-day work in the past, and honestly I found it maddening. I couldn't fully utilize my computer without starving the host of resources, and there were a thousand other papercuts relating to hardware access and general instability. I try to avoid that development story these days. As you can see, my concerns here have nothing to do with losing code or data. They relate to lost productivity and not satisfying my primary duties.
  - sshine 2y ago
    > a VM for my work doesn't change anything For complex software, real-life testing all the corners is impossible. You'd get some value out of people running it on VMs, some people running it on the same old hardware, some people running it on cutting-edge hardware, some people running it for extended periods and doing dist-upgrades, some people constantly reinstalling it (even within a VM). There are so many places software could fail. Especially things that aren't repeated often seem to fail: For example, websites where logging in works, but creating a user fails and nobody notices, because all employees already have accounts.
    - kyrofa 2y ago
      I think you're misinterpreting my response. Of course there's value in testing operating systems within VMs. In fact, a solid chunk (if not most) of the Ubuntu install-base is VMs, believe it or not. I wasn't talking about that at all, but rather responding to the idea that, if I used a VM as my development platform, my problems would go away. In reality, in that context, it really changes nothing.
  - wink 2y ago