3 ms·

> You know how crappy software is crappy in ways that are so blatantly obvious to the user that you wonder why it was released? It has crossed my mind several

> You know how crappy software is crappy in ways that are so blatantly obvious to the user that you wonder why it was released? It has crossed my mind several times recently that I want a word to describe this exact state of affairs. Where a thing has a defect so blatant that it is evident to any user that the creator of the thing has never tried using it. Eg. an airbnb with no towels in it. What's the word for this situation?

JSR_FDED 3y ago
Microsoft Teams
dkasper 3y ago
Fugazi is my favorite word for it. Also snafu.
fbergen 3y ago
Yet still people are using it? Otherwise it’s called an MVP and a promise of plugging the holes
- pdimitar 3y ago
  Come on now, you were never told in your career, not once, "we use Microsoft Teams for communication here"? Ever? Most crappy software exists because of inertia and corporate policies. If people truly had a choice stuff like MS Teams could be phased out by the end of the next quarter.
- crabbone 3y ago
  It's overly naive to think that people who use such a tool choose to use it. In many cases it's "you are hired into this job, this is the tool we give you, if you don't like the tool, take a hike". Even more so, a lot of software is developed not to be competitive, but to be exclusive. It's a lot easier to be the only choice for doing something than trying to compete with a different tool. I've seen countless examples of tools developed in exactly this paradigm, where the decision to use the tool wasn't made by anyone anywhere close the users of the tool (eg. hospital procurement department buying a PACS or a large avionics company ordering a custom-made budget-management program).
PaulDavisThe1st 3y ago
A tool with more than one way to use it?
crabbone 3y ago
I want to expand on this :) When I have to describe to people who don't work with me my interactions with developers (especially of the crappy code like that) from a standpoint of someone who represents the QA side of things... I describe to them my interactions with my five y.o. son: Me: How as school? Son: Goooood! Me: Did you behave? Son: Yes! Me: Did the teacher send you into timeout? Son: Yes... Me: So how come? You told me you behaved... What did you do? Son: Played with Ryan! Me: That doesn't seem like a good reason to send you into timeout. And we go like this until I either discover that he was yelling in class or I will never know the reason why he was in detention. This is also the pattern of denial I very frequently face when talking to the programmers who wrote the crappy code. Somewhere on the back of their minds they understand that they screwed up, but they will come up with all sorts of concocted reasoning to pretend that they either don't understand why the product sucks, or they would claim that it cannot be made any better, or attack me for not understanding how the product is supposed to work etc. The most recent example would be (in slight adaptation): Me: I discovered that we set PYTHONPATH variable when loading a (Tcl) module. Dev: I see no problems with that. Me: The new feature we are releasing to the users is conda support. Conda will not work (well) when this variable is set. Dev: Did the documentation tell users to load this module? Me: No, but it's obvious that users would like the functionality provided by the module in addition to using conda. They are made to complement each other. Besides, documentation doesn't say they shouldn't. Dev: (summons PM) And then PM continues in the same spirit as the developer. And, my guess is that the reason for it is that nobody really wants to work too hard. There's no reward in making a better quality product if that quality isn't immediately appreciated. Features like latency, throughput, size etc. are immediately visible to the user and are an easy sell. Features like internal consistency in the face of more sophisticated usage: these might never happen, and the user might never know that they were protected from their system collapsing on them by a substantial development effort. So, commercial companies de-prioritize quality. And that's how we get crappy programs.
- pdimitar 3y ago
  > And, my guess is that the reason for it is that nobody really wants to work too hard. There is certainly a lot of that but it gets even worse: you get actively punished for doing good work in many companies: you end up making other people work like asking managers around for product requirements (that are of course barely written somewhere, if at all) or reminding that sysadmin that they half-arsed the job of the deployment and now must add another k8s resource, or asking another dev why did they do X with the Y library... you want to make sure not to screw something up but you just end up annoying them. And sadly these things get brought up on meetings. And many over-zealous managers will scold you because they don't like the boat rocked (even if they would actually welcome their initiative; but that assumes they'd have made an effort to understand the situation which is not a given). It's no surprise that many talented people just end up checking in, doing the bare minimum, and clocking out. The equation is extremely easy to solve: "work X*3, get scolded, don't get promotions, accumulate hostility in colleagues" vs. "work X and have peace and quiet".

JSR_FDED 3y ago

Microsoft Teams

dkasper 3y ago

Fugazi is my favorite word for it. Also snafu.

fbergen 3y ago

Yet still people are using it? Otherwise it’s called an MVP and a promise of plugging the holes

pdimitar 3y ago
Come on now, you were never told in your career, not once, "we use Microsoft Teams for communication here"? Ever? Most crappy software exists because of inertia and corporate policies. If people truly had a choice stuff like MS Teams could be phased out by the end of the next quarter.
crabbone 3y ago
It's overly naive to think that people who use such a tool choose to use it. In many cases it's "you are hired into this job, this is the tool we give you, if you don't like the tool, take a hike". Even more so, a lot of software is developed not to be competitive, but to be exclusive. It's a lot easier to be the only choice for doing something than trying to compete with a different tool. I've seen countless examples of tools developed in exactly this paradigm, where the decision to use the tool wasn't made by anyone anywhere close the users of the tool (eg. hospital procurement department buying a PACS or a large avionics company ordering a custom-made budget-management program).

PaulDavisThe1st 3y ago

A tool with more than one way to use it?

crabbone 3y ago

I want to expand on this :) When I have to describe to people who don't work with me my interactions with developers (especially of the crappy code like that) from a standpoint of someone who represents the QA side of things... I describe to them my interactions with my five y.o. son: Me: How as school? Son: Goooood! Me: Did you behave? Son: Yes! Me: Did the teacher send you into timeout? Son: Yes... Me: So how come? You told me you behaved... What did you do? Son: Played with Ryan! Me: That doesn't seem like a good reason to send you into timeout. And we go like this until I either discover that he was yelling in class or I will never know the reason why he was in detention. This is also the pattern of denial I very frequently face when talking to the programmers who wrote the crappy code. Somewhere on the back of their minds they understand that they screwed up, but they will come up with all sorts of concocted reasoning to pretend that they either don't understand why the product sucks, or they would claim that it cannot be made any better, or attack me for not understanding how the product is supposed to work etc. The most recent example would be (in slight adaptation): Me: I discovered that we set PYTHONPATH variable when loading a (Tcl) module. Dev: I see no problems with that. Me: The new feature we are releasing to the users is conda support. Conda will not work (well) when this variable is set. Dev: Did the documentation tell users to load this module? Me: No, but it's obvious that users would like the functionality provided by the module in addition to using conda. They are made to complement each other. Besides, documentation doesn't say they shouldn't. Dev: (summons PM) And then PM continues in the same spirit as the developer. And, my guess is that the reason for it is that nobody really wants to work too hard. There's no reward in making a better quality product if that quality isn't immediately appreciated. Features like latency, throughput, size etc. are immediately visible to the user and are an easy sell. Features like internal consistency in the face of more sophisticated usage: these might never happen, and the user might never know that they were protected from their system collapsing on them by a substantial development effort. So, commercial companies de-prioritize quality. And that's how we get crappy programs.

pdimitar 3y ago
> And, my guess is that the reason for it is that nobody really wants to work too hard. There is certainly a lot of that but it gets even worse: you get actively punished for doing good work in many companies: you end up making other people work like asking managers around for product requirements (that are of course barely written somewhere, if at all) or reminding that sysadmin that they half-arsed the job of the deployment and now must add another k8s resource, or asking another dev why did they do X with the Y library... you want to make sure not to screw something up but you just end up annoying them. And sadly these things get brought up on meetings. And many over-zealous managers will scold you because they don't like the boat rocked (even if they would actually welcome their initiative; but that assumes they'd have made an effort to understand the situation which is not a given). It's no surprise that many talented people just end up checking in, doing the bare minimum, and clocking out. The equation is extremely easy to solve: "work X*3, get scolded, don't get promotions, accumulate hostility in colleagues" vs. "work X and have peace and quiet".