Hacker News Reader

Comment by aleph_minus_one | Hacker News Reader

> 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).

View on HN

If CEOs were legally required to regularly use their own products as an ordinary customer, the world would be a better place.

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.

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.

> 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,. :-)

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.

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.

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.

> 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.

Yes, but the end users are not (yet) code, they are humans. In order to fix the data in the system, the organization will have to place a human behind the keyboard with the authority and ability to change the data from incorrect to correct.

> will have to place a human behind the keyboard with the authority [...] to change the data from incorrect to correct.

Whether such a person has such a permission in the system or whether the permission system of the software can actually model this is a work process that has been turned into code.

Yes, the permissions systems in software usually is built to reflect the reality of someone's job role.

"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.

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.

Reply on news.ycombinator.com