5 ms·

What software is bad precisely? The modern browsers? The tools we use to build modern browser apps? Perhaps your gripe is with something else entirely, like mod

What software is bad precisely? The modern browsers? The tools we use to build modern browser apps? Perhaps your gripe is with something else entirely, like modern databases? Or is it the OS that you don't like? Really not sure what you're commenting about here

Godel_unicode 4y ago
They said that the world is bad software on top of bad software, so it’s not one thing. It’s everything being bad and working around everything else being bad.
- voidfunc 4y ago
  Yea but they didn’t explain why its bad. Software devs complaining about “bad software” is basically an industry trope at this point but often it just means “Its too complex and I don’t understand why that complexity is probably necessary” or “Its not written the way I would have written it”.
- arinlen 4y ago
  > They said that the world is bad software on top of bad software, so it’s not one thing. I don't know about OP, but I personally feel like software like GCC/clang/MSVC and Debian/Ubuntu and Docker and SSH and Git are pretty great, and were never better. Heck, the whole dotnet ecosystem is turning some significant problems in developer experience into at most minor nuisances. Even Firefox+Chrome are stellar, and extremely solid as-is. Where exactly is this bad software OP is talking about?
  - happymellon 4y ago
    In my experience it's the custom scripts in an attempt to separate infra from developers. If you are using one of the major cloud providers and instead of just using a native IaC scripts, you have decided that it would be better if the developers only had access to your custom kubernetes operators to manage their infrastructure then you are the problem. If you are using a deployment pipeline that developers have zero involvement in, and they just "import your Jenkins scripts" then you are the problem. If you are using major cloud provider and rather than just using their managed kubernetes, you have decided to deploy your own, then the chances are that you are the problem. Rarely have these approaches ever been stable, in my 20+ year experience they have never been stable. And they are the reason that "real DevOps" came along because developers could do a better job with less downtime if people actually engaged them.
cshenton 4y ago
Why not all of the above?
metadat 4y ago
Some people feel anything not written or created by them is "bad". It doesn't matter to me who turned the wrench, but in my career I've encountered these types where it's only good enough if it's theirs. And IMHO their output is generally quite atrocious. Root cause: Psychological issues.
- hinkley 4y ago
  Shit most of the stuff I write is bad too. What’s missing a lot is empathy, and that takes slowing down and observing.
  - patrick451 4y ago
    We have way too much empathy for bad software. Honestly, it's almost all total shit. If my care was as bad as the median level of software, it would last 30 days and then be broken down in my driveway until the scrapper hauls it off.
    - kaba0 4y ago
      What part of the stack you think of? Because my experience is that the underlying stuff Just Works^TM. Sure, it does have the occasional hiccup, but 1 out of 1000, it is some higher level tool that has a bug. Just to share the terminology, under underlying stuff I mean the linux kernel, the JVM, etc, while higher level stuff could be certain build tools (khm, looking at you npm), and of course end user tools that are unfortunately way too buggy. Like I have a hard time listing end user applications where I didn’t notice a bug yet.
    - hinkley 4y ago
      I feel like there's an opportunity missed here with the transition to clustering for us to build a small kernel for running simple services and moving things over to run on top of these things. Give me a tight, highly coherent API, with a culture of avoiding feature factory work. At least get "Make it work, make it right, make it fast" to not skip "make it right" anymore. That's sort of the core illness in software today. Open source doesn't have to be pushed by business concerns. There's a degree of regulatory capture, but the biggest problem is that we just don't know any better. We repeat what we see, and make sure our own pain points are handled. I've seen this play out in API design where an awful API is introduced, and each person who fixes it only fixes 20% of the pain, and so it's 10 years before we get from a mediocre library to one you could actually call 'good', because nobody made 'good', they made better than better than better than ridiculous.

Godel_unicode 4y ago

They said that the world is bad software on top of bad software, so it’s not one thing. It’s everything being bad and working around everything else being bad.

voidfunc 4y ago
Yea but they didn’t explain why its bad. Software devs complaining about “bad software” is basically an industry trope at this point but often it just means “Its too complex and I don’t understand why that complexity is probably necessary” or “Its not written the way I would have written it”.
arinlen 4y ago
> They said that the world is bad software on top of bad software, so it’s not one thing. I don't know about OP, but I personally feel like software like GCC/clang/MSVC and Debian/Ubuntu and Docker and SSH and Git are pretty great, and were never better. Heck, the whole dotnet ecosystem is turning some significant problems in developer experience into at most minor nuisances. Even Firefox+Chrome are stellar, and extremely solid as-is. Where exactly is this bad software OP is talking about?
- happymellon 4y ago
  In my experience it's the custom scripts in an attempt to separate infra from developers. If you are using one of the major cloud providers and instead of just using a native IaC scripts, you have decided that it would be better if the developers only had access to your custom kubernetes operators to manage their infrastructure then you are the problem. If you are using a deployment pipeline that developers have zero involvement in, and they just "import your Jenkins scripts" then you are the problem. If you are using major cloud provider and rather than just using their managed kubernetes, you have decided to deploy your own, then the chances are that you are the problem. Rarely have these approaches ever been stable, in my 20+ year experience they have never been stable. And they are the reason that "real DevOps" came along because developers could do a better job with less downtime if people actually engaged them.

cshenton 4y ago

Why not all of the above?

metadat 4y ago

Some people feel anything not written or created by them is "bad". It doesn't matter to me who turned the wrench, but in my career I've encountered these types where it's only good enough if it's theirs. And IMHO their output is generally quite atrocious. Root cause: Psychological issues.

hinkley 4y ago
Shit most of the stuff I write is bad too. What’s missing a lot is empathy, and that takes slowing down and observing.
- patrick451 4y ago
  We have way too much empathy for bad software. Honestly, it's almost all total shit. If my care was as bad as the median level of software, it would last 30 days and then be broken down in my driveway until the scrapper hauls it off.
  - kaba0 4y ago
    What part of the stack you think of? Because my experience is that the underlying stuff Just Works^TM. Sure, it does have the occasional hiccup, but 1 out of 1000, it is some higher level tool that has a bug. Just to share the terminology, under underlying stuff I mean the linux kernel, the JVM, etc, while higher level stuff could be certain build tools (khm, looking at you npm), and of course end user tools that are unfortunately way too buggy. Like I have a hard time listing end user applications where I didn’t notice a bug yet.
  - hinkley 4y ago
    I feel like there's an opportunity missed here with the transition to clustering for us to build a small kernel for running simple services and moving things over to run on top of these things. Give me a tight, highly coherent API, with a culture of avoiding feature factory work. At least get "Make it work, make it right, make it fast" to not skip "make it right" anymore. That's sort of the core illness in software today. Open source doesn't have to be pushed by business concerns. There's a degree of regulatory capture, but the biggest problem is that we just don't know any better. We repeat what we see, and make sure our own pain points are handled. I've seen this play out in API design where an awful API is introduced, and each person who fixes it only fixes 20% of the pain, and so it's 10 years before we get from a mediocre library to one you could actually call 'good', because nobody made 'good', they made better than better than better than ridiculous.