[phrotoma]

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

Microsoft Teams

[fbergen]

Yet still people are using it?

Otherwise it’s called an MVP and a promise of plugging the holes

[crabbone]

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

[pdimitar]

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.

[dkasper]

Fugazi is my favorite word for it. Also snafu.

[PaulDavisThe1st]

A tool with more than one way to use it?

[crabbone]

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]

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

[crabbone]

Haha. Yeah. I almost got fired in my first month because I asked another developer something I thought was really innocent: they mixed some code from pytest with unittest (two competing Python unit-testing libraries) where either one or the other could do the job perfectly fine. So, I naturally asked why'd they do it. Not even being mean. They, of course, interpreted this as me being snarky... complained to the management, and I had to look for another department to house me.

Now I write "sorry" and "excuse me" when I get assigned to review someone's code and I mostly fix typos in the comments. But, even so, I don't get assigned to code reviews all that often :)

[pdimitar]

Yep, had several similar such occurrences and my mind is boggled every time. I personally welcome any opportunity to learn and improve, but many people apparently don't.

[Kon-Peki]

Not knowing anything other than what you wrote, it sounds like your organization has leadership problems. People don't know why their job exists, they don't know what your organization is actually trying to accomplish, how any individual person fits into it, why the day-to-day things someone does helps, etc.

Nothing anyone does with software will help.

[pdimitar]

> it sounds like your organization has leadership problems

That's like saying "sounds like the Sun is going to rise tomorrow again". Most companies have leadership problems, it's kind of ingrained in Homo Sapiens to fight for a cozy position and then become a gatekeeper of their own mediocrity, to the detriment of their rulers.

[crabbone]

Yeah, but the most disappointing part is that you cannot say it out loud. Even acknowledging the problem will have all the swords pointing at you. So, everyone quietly hates their pointless tasks, but completes them somehow anyways. And things only get worse :) But, there's no reality check because there's no competition and hasn't been for such a long time that users are essentially led to believe that what they are getting is the best they can get.