5 ms·

> Whoever built this didn't test it on the ground. God this happens all the time. Software written by people that don't use the software themselves. It has hap

> Whoever built this didn't test it on the ground. God this happens all the time. Software written by people that don't use the software themselves. It has happened to me so many times, I come across a piece of software with weird bugs or interactions that would be immediately fixed if the developer just spends 5 minutes using the software like an end user would. Dogfood all the things!

aleph_minus_one 24d ago
> Software written by people that don't use the software themselves. It has happened to me so many times, I come across a piece of software with weird bugs or interactions that would be immediately fixed if the developer just spends 5 minutes using the software like an end user would. Dogfood all the things! My experience is completely contrary: developers typically do care deeply about such things. The problem is rather that very commonly managers actively disallow these poor developers to apply their diligence to the software that they develop. I really have a strong feeling that you want to participate in the ugly vendetta against software developers that has been going on for decades ("Replace all software developers"; current season: "Replace them with AI"). Don't do that. Rather fight the people who are really responsible (who are often (project) managers or Scrum masters).
- lukan 24d ago
  "I really have a strong feeling that you want to participate in the ugly vendetta against software developers that has been going on for decades ("Replace all software developers"; current season: "Replace them with AI")." Paranoia? There are a lot of devs who don't really like what they develope so don't spend any time dogfooding it. Has nothing to do with devs who are blocked by management.
  - aleph_minus_one 24d ago
    > There are a lot of devs who don't really like what they develope so don't spend any time dogfooding it. Note that in my comment I wrote nothing about dogfooding - for a very good reason: It is well-known that dogfooding leads to software that has rather few bugs, but also dogfooded software often shows a tendency to be "biased towards programmers and power users". So, there often exist very good reasons if the programmers actively don't dogfood their software, and rather trust someone else (who is very trusted by the programmers) that the workflow that the programmer should implement does make sense for the user, even though most programmers would implement this aspect very differently.
    - msdz 24d ago
      Okay, so what I’m taking away and remembering here is that if I wrote software for programmers/“power users”, I should dogfood as much as possible, right? :-)
      - lukan 24d ago
        Well, I think you should always do that(if your constraints let you). But working with actual users and valuing their input is to be prefered of course. Every user can be a power user if you give them the tools so they empower themself.
      - aleph_minus_one 24d ago
        > Okay, so what I’m taking away and remembering here is that if I wrote software for programmers/“power users”, I should dogfood as much as possible, right? :-) Lessons that you should be taking away are rather: - Every tool that possibly might be good for improving the quality of the software is just a tool that can also cause harm if used in a wrong way. - Deeply distrust keynote speakers and thought leaders who sell their method for improving the quality of the software or improving software development as a panacea. Every method is only useful under specific circumstances and is harmful of used wrongly. Keynote speakers and thought leaders who don't go into details when their methods are helpful and when they are harmful are simply scammers and snake oil salesmen and should be called this.
  - jeltz 24d ago
    No, while the patent poster expresses their opinion quite strongly I have more than once encountered product managers and project managers who get almost personally offended when developers try to use their brains and don't just blindly implement incorrect specifications. If they have a vendetta I don't know but they clearly hate having to depend on engineers with free will. That said I have also encountered lazy engineers who are totally fine with implementing obviously broken software, those are a perfect match for the egotistical product manager.
    - tcmart14 24d ago
      Shoot where I am at, it can also change on a week by week basis. This week, I can get away with some shit to improve the UX and depart from the mock up. Next week, if the feature doesn't look and function just like the mock up says that was handed in the case, I'm in trouble. No matter how bad it is.
- bombcar 24d ago
  Sometimes it's so painfully obvious - that you can turn a piece of crApp into something that works well by just modifying yourself or the situation so you're following the path that the developers do.
- wat10000 24d ago
  If CEOs were legally required to regularly use their own products as an ordinary customer, the world would be a better place.
  - SaltyBackendGuy 24d ago
    Slightly off topic, but I strongly believe that the rise of "professional" CEOs was the beginning of the end for quality products and services. Before, you were generally an expert in your particular domain and was invested in solving the customer's problems.
    - FireBeyond 24d ago
      I recently worked for a company in the cybersecurity space who hired a CEO who had neither IT, nor security, nor cybersecurity experience... ... I saw last week that they just had their (latest) 25% headcount reduction, followed by their (latest) "executive offsite retreat" to pat each other on the back and figure out what they'll do between now and the next one.
  - aleph_minus_one 24d ago
    > If CEOs were legally required to regularly use their own products as an ordinary customer, the world would be a better place. This is like the argument "developers should use the software that they write" (dogfooding). Let me give one example: the previous person who designed and developed the previous version of the software which I now work on really could use "his" program insanely well. The problem was rather that he was basically the only person who really did understand it sufficiently well to not to be triggered by problems other users had. Yes, a huge part of my job is over the years to turn this piece of software into something that is understandable by other people, too,. :-)
- kube-system 24d ago
  Bugs caused by edge-cases in data are exactly the types of bugs that are usually not caught in smoke tests. In my experience with large regulated systems, the engineers writing the software don't have the expertise to even know what the correct specifications should be in most cases, and especially in edge cases. Software engineers are not experts in customs and immigration legal requirements and would be relying on heavily on guidance from experts in those fields to determine the proper rules to apply. In my experience with bugs like this, it is usually scenarios that all parties involved in the design did not consider... especially when implementation is rushed due to tight deadlines.
  - aleph_minus_one 24d ago
    My experience is rather that the typical software developer is ultra-cautious, and will always leave some loophole open in the workflows of the software in case something unexpected occurs that could not be foreseen, in particular considering the high stakes that are involved when something goes wrong with the software: I am not exaggerating when I claim that if something like what is is described in the article happens to some people, they often will start praying to their god that he kills the responsible people for this bug in the software in the most brutal imaginable way. Software developers know that. Other stakeholders typically don't apply such caution.
    - kube-system 24d ago
      Yeah, the typical way to fix an unforeseen data issue is that someone is empowered to update the data manually on the backend which sounds like exactly what happened. That being a slow process is not a software engineering issue, but an organizational issue.
      - aleph_minus_one 24d ago
        > That being a slow process is not a software engineering issue, but an organizational issue. Business software is work processes that has been turned into code.
pennomi 24d ago
I’ve been in the weird situation of working in a startup where the founder doesn’t use their own product. Needless to say I got out of there pretty quick.
dylan604 24d ago
I write software that we use daily, and we still find things in the wild that we would never find until the thing in the wild occurs. Luckily for me, none of these found in the wild issues interfere with people's lives and just means a file gets completed a little closer to the deadline. I'm fine with that. Not sure if this situation falls under the "push it to prod and let the users QA it" or if this is truly edge case situations. It's easy to bash and make fun of, but I've been in the trenches of catching what is an edge case for most people but run of the mill for those providing the data to me.

aleph_minus_one 24d ago

> Software written by people that don't use the software themselves. It has happened to me so many times, I come across a piece of software with weird bugs or interactions that would be immediately fixed if the developer just spends 5 minutes using the software like an end user would. Dogfood all the things! My experience is completely contrary: developers typically do care deeply about such things. The problem is rather that very commonly managers actively disallow these poor developers to apply their diligence to the software that they develop. I really have a strong feeling that you want to participate in the ugly vendetta against software developers that has been going on for decades ("Replace all software developers"; current season: "Replace them with AI"). Don't do that. Rather fight the people who are really responsible (who are often (project) managers or Scrum masters).

lukan 24d ago
"I really have a strong feeling that you want to participate in the ugly vendetta against software developers that has been going on for decades ("Replace all software developers"; current season: "Replace them with AI")." Paranoia? There are a lot of devs who don't really like what they develope so don't spend any time dogfooding it. Has nothing to do with devs who are blocked by management.
- aleph_minus_one 24d ago
  > There are a lot of devs who don't really like what they develope so don't spend any time dogfooding it. Note that in my comment I wrote nothing about dogfooding - for a very good reason: It is well-known that dogfooding leads to software that has rather few bugs, but also dogfooded software often shows a tendency to be "biased towards programmers and power users". So, there often exist very good reasons if the programmers actively don't dogfood their software, and rather trust someone else (who is very trusted by the programmers) that the workflow that the programmer should implement does make sense for the user, even though most programmers would implement this aspect very differently.
  - msdz 24d ago
    Okay, so what I’m taking away and remembering here is that if I wrote software for programmers/“power users”, I should dogfood as much as possible, right? :-)
    - lukan 24d ago
      Well, I think you should always do that(if your constraints let you). But working with actual users and valuing their input is to be prefered of course. Every user can be a power user if you give them the tools so they empower themself.
    - aleph_minus_one 24d ago
      > Okay, so what I’m taking away and remembering here is that if I wrote software for programmers/“power users”, I should dogfood as much as possible, right? :-) Lessons that you should be taking away are rather: - Every tool that possibly might be good for improving the quality of the software is just a tool that can also cause harm if used in a wrong way. - Deeply distrust keynote speakers and thought leaders who sell their method for improving the quality of the software or improving software development as a panacea. Every method is only useful under specific circumstances and is harmful of used wrongly. Keynote speakers and thought leaders who don't go into details when their methods are helpful and when they are harmful are simply scammers and snake oil salesmen and should be called this.
- jeltz 24d ago
  No, while the patent poster expresses their opinion quite strongly I have more than once encountered product managers and project managers who get almost personally offended when developers try to use their brains and don't just blindly implement incorrect specifications. If they have a vendetta I don't know but they clearly hate having to depend on engineers with free will. That said I have also encountered lazy engineers who are totally fine with implementing obviously broken software, those are a perfect match for the egotistical product manager.
  - tcmart14 24d ago
    Shoot where I am at, it can also change on a week by week basis. This week, I can get away with some shit to improve the UX and depart from the mock up. Next week, if the feature doesn't look and function just like the mock up says that was handed in the case, I'm in trouble. No matter how bad it is.
bombcar 24d ago
Sometimes it's so painfully obvious - that you can turn a piece of crApp into something that works well by just modifying yourself or the situation so you're following the path that the developers do.
wat10000 24d ago
If CEOs were legally required to regularly use their own products as an ordinary customer, the world would be a better place.
- SaltyBackendGuy 24d ago
  Slightly off topic, but I strongly believe that the rise of "professional" CEOs was the beginning of the end for quality products and services. Before, you were generally an expert in your particular domain and was invested in solving the customer's problems.
  - FireBeyond 24d ago
    I recently worked for a company in the cybersecurity space who hired a CEO who had neither IT, nor security, nor cybersecurity experience... ... I saw last week that they just had their (latest) 25% headcount reduction, followed by their (latest) "executive offsite retreat" to pat each other on the back and figure out what they'll do between now and the next one.
- aleph_minus_one 24d ago
  > If CEOs were legally required to regularly use their own products as an ordinary customer, the world would be a better place. This is like the argument "developers should use the software that they write" (dogfooding). Let me give one example: the previous person who designed and developed the previous version of the software which I now work on really could use "his" program insanely well. The problem was rather that he was basically the only person who really did understand it sufficiently well to not to be triggered by problems other users had. Yes, a huge part of my job is over the years to turn this piece of software into something that is understandable by other people, too,. :-)
kube-system 24d ago
Bugs caused by edge-cases in data are exactly the types of bugs that are usually not caught in smoke tests. In my experience with large regulated systems, the engineers writing the software don't have the expertise to even know what the correct specifications should be in most cases, and especially in edge cases. Software engineers are not experts in customs and immigration legal requirements and would be relying on heavily on guidance from experts in those fields to determine the proper rules to apply. In my experience with bugs like this, it is usually scenarios that all parties involved in the design did not consider... especially when implementation is rushed due to tight deadlines.
- aleph_minus_one 24d ago
  My experience is rather that the typical software developer is ultra-cautious, and will always leave some loophole open in the workflows of the software in case something unexpected occurs that could not be foreseen, in particular considering the high stakes that are involved when something goes wrong with the software: I am not exaggerating when I claim that if something like what is is described in the article happens to some people, they often will start praying to their god that he kills the responsible people for this bug in the software in the most brutal imaginable way. Software developers know that. Other stakeholders typically don't apply such caution.
  - kube-system 24d ago
    Yeah, the typical way to fix an unforeseen data issue is that someone is empowered to update the data manually on the backend which sounds like exactly what happened. That being a slow process is not a software engineering issue, but an organizational issue.
    - aleph_minus_one 24d ago
      > That being a slow process is not a software engineering issue, but an organizational issue. Business software is work processes that has been turned into code.

pennomi 24d ago

I’ve been in the weird situation of working in a startup where the founder doesn’t use their own product. Needless to say I got out of there pretty quick.

dylan604 24d ago

I write software that we use daily, and we still find things in the wild that we would never find until the thing in the wild occurs. Luckily for me, none of these found in the wild issues interfere with people's lives and just means a file gets completed a little closer to the deadline. I'm fine with that. Not sure if this situation falls under the "push it to prod and let the users QA it" or if this is truly edge case situations. It's easy to bash and make fun of, but I've been in the trenches of catching what is an edge case for most people but run of the mill for those providing the data to me.