8 ms·

My classic C programmer curmudgeon take is that the root of the problem, as with everything else in this industry, is bad software built on top of bad software

My classic C programmer curmudgeon take is that the root of the problem, as with everything else in this industry, is bad software built on top of bad software built on top of bad software... and on it goes. The systems in your 2022 world are hard to test and maintain because they are bad, and the tools we built to test and maintain them are largely built on the same foundational ideas and technologies, so they are even worse. We're going to have to rip everything back down to the foundation in order to make progress beyond finger-pointing (X is DevOps but Y is software engineering and Z is IT admin).

theflyinghorse 4y ago
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.
phillipcarter 4y ago
Talk about a low-effort take on the state of modern software. You know what’s also “just bad”? Most systems software written in C.
- stathibus 4y ago
  We could do a case study or something, but that would be a blog post or a book, not an HN comment. How much effort are you looking for here?
- no-dr-onboard 4y ago
  I was put off by the low effort take as well. Personally, I’ve worked through having this mindset myself. I “grew” up with the C and tots descendant family of languages. I wrote shellcode in C and ASM as an exploit dev. I later learned python and now ruby, arguably some of the most abstracted languages. At each iteration I openly opined at how “C would let me do X without the handcuffs I put myself in by using Language Y”. It’s really just senseless complaining. There is a reason why someone chose Ruby over PHP. PHP over pascal, Pascal over Ada and so on. The point is, to scoff at the product as a bystander is just immature. Throwing shade on an entire industry based off some weird pet purist outlook is just immature :/. Of course, the irony here is that this type of mindset is no different from the apprentice carpenter who scoffs at every new house he walks through that he didn’t build. It’s no different from the wine snob who cringes at what his mom puts out when company is over. It’s no different from the tens of submissions HN accumulated in a week with something of the tune “I rewrote X in Rust”.
anothernewdude 4y ago
Expecting all software in a properly written stack to be "good" is a particularly bad take, and one that leads to brittle software. Best to accept reality, deal with it and move on.
bitwize 4y ago
Your classic C programmer take comes from a time and place where servers were pets and nobody had to, or could, scale very big. The fact is that businesses either are or are converting to cloud-first because why incur the risks of maintaining the one special-snowflake server that runs your business when you can turn a crank and spin up as many instances as you need -- theoretically very many as you take on more customers and transactions and need to handle the load? And ypu can just restart them if they go down? Stop thinking technology and start thinking BUSINESS. The cloud may be more janky and complicated than what you're used to but it serves the business's needs better.
- jacquesm 4y ago
  Lots of companies excel at playing big business without actually being a big business (or having a remote chance of becoming one). They simply lug around the kind of infrastructure that might be suitable for a company ten times their size. Ironically, it isn't rare that that extra infrastructure and the cost and effort to maintain it limit them in the marketplace.
- lelanthran 4y ago
  > The fact is that businesses either are or are converting to cloud-first because why incur the risks of maintaining the one special-snowflake server that runs your business when you can turn a crank and spin up as many instances as you need -- theoretically very many as you take on more customers and transactions and need to handle the load? And ypu can just restart them if they go down? I'm pretty certain you can do the same with software written in C (or any other language) without resorting to AWS/Azure/GCP/etc. You can do the same cranking on your own hardware, except you keep the hardware after the peak has passed and you need to plan for the peak. Or, you can simply get a DO droplet, and crank out as many new instances as you need, and turn them off when you don't, with software written in C (or anything else). There's no need to go all-in on the AWS/Azure/GCP solution, with the ability to orchestrate instances as cattle, when you have, at peak, 3 instances[1]. [1]If you wrote your software in C, or Rust, or Go instead of Python, or Ruby, you could potentially get away with fewer instances than you need, thereby reducing to treating the system as a system of pets because there are so few of them.
vinyl7 4y ago
The reason is this: To make money in a gold rush, sell shovels. Everyone wants to bank on the software craze, and so everyone develops pointless middleware solutions.
- drpyser22 4y ago
  That's a bit disingenuous to actual engineers trying to solve problems and genuinely believing their solution can make things better. Also, looking at principles over tooling, DevOps has a lot to offer that trivially make sense.
- pjmlp 4y ago
  You're forgetting the conferences, books, trainings, consulting gigs.
deleted 4y ago
[deleted]
posnet 4y ago
You are not alone in thinking that, see 'The Thirty Million Line' talk by Casey Muratori. (Long, but worth it, assuming you haven't seen it already) https://www.youtube.com/watch?v=kZRE7HIO3vk https://www.youtube.com/watch?v=kZRE7HIO3vk
dasz 4y ago
I don't think we need to muddy the water by saying bad software. Just write the word software. It's multiple layers upon layers. This isn't automatically bad. There's so much more going on. I don't know if the complexity is all required but we're doing more now. There's just more going on. That's how it is. We need the abstractions. Maybe not all of them. But we need more abstractions and tools running now. There's so much to manage. I don't see us reducing this complexity that much other than consolidation and some simplification to clean things as they get sorted further. But there is still a need for the layers. It's not 2005. Things are more complex. The nearest analogy is would you like to code everything in line numbered BASIC or would you like to do it using some modern equivalent? Even with the additional layers there has been real progress in the tools. Improvements across a multitude of metrics. It's not all complexity for the sake of complexity. Smile. It's another stage of progress. The old mess will fall away. At the next stage what we see as an improvement now will be the next stage's mess. There's a whole slew of problems that will need even newer tools. We haven't even scratched the surface of the automation we'll require in ten years time.
oblio 4y ago
> We're going to have to rip everything back down to the foundation in order to make progress beyond finger-pointing (X is DevOps but Y is software engineering and Z is IT admin). 1. Never going to happen unless everything collapses, which is extremely unlikely. 2. We are progressing. AR, VR, GPUs with raytracing, complex web applications and global services, global cloud, etc.
1vuio0pswjnm7 4y ago
To whom does "we" refer. The classic C programmer curmudgeon. Those commenting on HN frequently use the term "we" but reading HN one can see that, amongst those commenting, there is a divergence of opinions about software. Who is "we". Asking prospective "DevOps", "software engineer" and "IT admin" candidates to program in C is an effective way to weed out those who are not truly capable of writing "good" software. It is easy to find mistakes and expose the incompetent. That may offend the incompetent who believe they are "good" programmers. Thus there are new programming languages created every year, more people using them to write "bad" software, and more people who feel emboldened to attack C as the source of problems, instead of "bad" programmers. C is truth serum. It is difficult for people programming in C to pretend they are "good" programmmers. They will be found out. It is funny how people on HN attack the language for exposing so many "bad" programmers. Under this theory, programmers are absolved of all responsibility for their mistakes. The language is at fault. "Good" programmers do not blame languages for their own mistakes. IMHO, there is sometimes a benefit to languages that make it more difficult, not easier, to create and sustain Rube Goldberg complexity. Not to mention languages that compile to smaller, faster programs. "Programmer productivity" is ambiguous. For example, it could be a positive for a programmer trying to justify the expense their salary presents to an employer or it could be a negative to people who are forced to use an ever-increasing quantity of "bad" software. It could be a positive to a programmer who wants to keep implementing new "features" or it could be a negative to a software user who dislikes "feature creep". The dichotomy of good versus bad software is such a subjective topic that the term "we" really needs to be defined. Different groups of people have different interests and therefore different opinions.
- mlyle 4y ago
  Hey, I've written more C code than anything else and was generally considered pretty competent. > The language is at fault. "Good" programmers do not blame languages for their mistakes. I also know that my time to get something functional in higher level languages is often 10x less, and my probability of having very subtle bugs to hunt is much lower. There's a super-weird tradeoff here. There's all kinds of modern, high-level techniques that improve programmer productivity and reliability of bigger systems.. They convert people who can't be productive C programmers into doing OK work. But they're also slow and a bit opaque in how they work. And it's really easy to run out of performance and have to do exotic things to get them to scale, in which case you have to build bigger systems still and cede a lot of those advantages. Whereas, if you write to the metal, you can get a lot of performance out of a single large computer.
arinlen 4y ago
> My classic C programmer curmudgeon take is that the root of the problem, as with everything else in this industry, is bad software built on top of bad software built on top of bad software... and on it goes. No, not really. Nowadays things are way way better than how they were a decade ago. Nowadays you can get pipelines that build and test on multiple target platforms with a dozen or so lines of code, and things run so well that they became reliable infrastructure integrated with your prod system. Back then you had none of this, and had to pay the salary for a "build engineer" who worked like a wizard stirring a cauldron just to get a single production build out of the door.
- blueflow 4y ago
  The bad things are still around in your infra even if you manage to never see them because you only see the "dozens lines of code" at the front.
  - mrjin 4y ago
    Someone who really buys that "dozens lines of code" will definitely has no idea what kind of complexity it was about.
- hinkley 4y ago
  I’ve been cultivating this opinion that it’s the other way around. In any other domain, few people use crap tools to make something amazing, and I think it comes down to what you surround yourself with informs what you make. We need better tools if we want better things.
- mrjin 4y ago
  Oh sure. Can you try to set up ANY CI pipelines to make it more or less working, don't worry about "pipelines that build and test on multiple target platforms" and get back to share with us your experiences?
  - allarm 4y ago
    What exactly do you want to hear? Not op, but I’ve been doing it for some time.

theflyinghorse 4y ago

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.

phillipcarter 4y ago

Talk about a low-effort take on the state of modern software. You know what’s also “just bad”? Most systems software written in C.

stathibus 4y ago
We could do a case study or something, but that would be a blog post or a book, not an HN comment. How much effort are you looking for here?
no-dr-onboard 4y ago
I was put off by the low effort take as well. Personally, I’ve worked through having this mindset myself. I “grew” up with the C and tots descendant family of languages. I wrote shellcode in C and ASM as an exploit dev. I later learned python and now ruby, arguably some of the most abstracted languages. At each iteration I openly opined at how “C would let me do X without the handcuffs I put myself in by using Language Y”. It’s really just senseless complaining. There is a reason why someone chose Ruby over PHP. PHP over pascal, Pascal over Ada and so on. The point is, to scoff at the product as a bystander is just immature. Throwing shade on an entire industry based off some weird pet purist outlook is just immature :/. Of course, the irony here is that this type of mindset is no different from the apprentice carpenter who scoffs at every new house he walks through that he didn’t build. It’s no different from the wine snob who cringes at what his mom puts out when company is over. It’s no different from the tens of submissions HN accumulated in a week with something of the tune “I rewrote X in Rust”.

anothernewdude 4y ago

Expecting all software in a properly written stack to be "good" is a particularly bad take, and one that leads to brittle software. Best to accept reality, deal with it and move on.

bitwize 4y ago

Your classic C programmer take comes from a time and place where servers were pets and nobody had to, or could, scale very big. The fact is that businesses either are or are converting to cloud-first because why incur the risks of maintaining the one special-snowflake server that runs your business when you can turn a crank and spin up as many instances as you need -- theoretically very many as you take on more customers and transactions and need to handle the load? And ypu can just restart them if they go down? Stop thinking technology and start thinking BUSINESS. The cloud may be more janky and complicated than what you're used to but it serves the business's needs better.

jacquesm 4y ago
Lots of companies excel at playing big business without actually being a big business (or having a remote chance of becoming one). They simply lug around the kind of infrastructure that might be suitable for a company ten times their size. Ironically, it isn't rare that that extra infrastructure and the cost and effort to maintain it limit them in the marketplace.
lelanthran 4y ago
> The fact is that businesses either are or are converting to cloud-first because why incur the risks of maintaining the one special-snowflake server that runs your business when you can turn a crank and spin up as many instances as you need -- theoretically very many as you take on more customers and transactions and need to handle the load? And ypu can just restart them if they go down? I'm pretty certain you can do the same with software written in C (or any other language) without resorting to AWS/Azure/GCP/etc. You can do the same cranking on your own hardware, except you keep the hardware after the peak has passed and you need to plan for the peak. Or, you can simply get a DO droplet, and crank out as many new instances as you need, and turn them off when you don't, with software written in C (or anything else). There's no need to go all-in on the AWS/Azure/GCP solution, with the ability to orchestrate instances as cattle, when you have, at peak, 3 instances[1]. [1]If you wrote your software in C, or Rust, or Go instead of Python, or Ruby, you could potentially get away with fewer instances than you need, thereby reducing to treating the system as a system of pets because there are so few of them.

vinyl7 4y ago

The reason is this: To make money in a gold rush, sell shovels. Everyone wants to bank on the software craze, and so everyone develops pointless middleware solutions.

drpyser22 4y ago
That's a bit disingenuous to actual engineers trying to solve problems and genuinely believing their solution can make things better. Also, looking at principles over tooling, DevOps has a lot to offer that trivially make sense.
pjmlp 4y ago
You're forgetting the conferences, books, trainings, consulting gigs.

deleted 4y ago

[deleted]

posnet 4y ago

You are not alone in thinking that, see 'The Thirty Million Line' talk by Casey Muratori. (Long, but worth it, assuming you haven't seen it already) https://www.youtube.com/watch?v=kZRE7HIO3vk https://www.youtube.com/watch?v=kZRE7HIO3vk

dasz 4y ago

I don't think we need to muddy the water by saying bad software. Just write the word software. It's multiple layers upon layers. This isn't automatically bad. There's so much more going on. I don't know if the complexity is all required but we're doing more now. There's just more going on. That's how it is. We need the abstractions. Maybe not all of them. But we need more abstractions and tools running now. There's so much to manage. I don't see us reducing this complexity that much other than consolidation and some simplification to clean things as they get sorted further. But there is still a need for the layers. It's not 2005. Things are more complex. The nearest analogy is would you like to code everything in line numbered BASIC or would you like to do it using some modern equivalent? Even with the additional layers there has been real progress in the tools. Improvements across a multitude of metrics. It's not all complexity for the sake of complexity. Smile. It's another stage of progress. The old mess will fall away. At the next stage what we see as an improvement now will be the next stage's mess. There's a whole slew of problems that will need even newer tools. We haven't even scratched the surface of the automation we'll require in ten years time.

oblio 4y ago

> We're going to have to rip everything back down to the foundation in order to make progress beyond finger-pointing (X is DevOps but Y is software engineering and Z is IT admin). 1. Never going to happen unless everything collapses, which is extremely unlikely. 2. We are progressing. AR, VR, GPUs with raytracing, complex web applications and global services, global cloud, etc.

1vuio0pswjnm7 4y ago

To whom does "we" refer. The classic C programmer curmudgeon. Those commenting on HN frequently use the term "we" but reading HN one can see that, amongst those commenting, there is a divergence of opinions about software. Who is "we". Asking prospective "DevOps", "software engineer" and "IT admin" candidates to program in C is an effective way to weed out those who are not truly capable of writing "good" software. It is easy to find mistakes and expose the incompetent. That may offend the incompetent who believe they are "good" programmers. Thus there are new programming languages created every year, more people using them to write "bad" software, and more people who feel emboldened to attack C as the source of problems, instead of "bad" programmers. C is truth serum. It is difficult for people programming in C to pretend they are "good" programmmers. They will be found out. It is funny how people on HN attack the language for exposing so many "bad" programmers. Under this theory, programmers are absolved of all responsibility for their mistakes. The language is at fault. "Good" programmers do not blame languages for their own mistakes. IMHO, there is sometimes a benefit to languages that make it more difficult, not easier, to create and sustain Rube Goldberg complexity. Not to mention languages that compile to smaller, faster programs. "Programmer productivity" is ambiguous. For example, it could be a positive for a programmer trying to justify the expense their salary presents to an employer or it could be a negative to people who are forced to use an ever-increasing quantity of "bad" software. It could be a positive to a programmer who wants to keep implementing new "features" or it could be a negative to a software user who dislikes "feature creep". The dichotomy of good versus bad software is such a subjective topic that the term "we" really needs to be defined. Different groups of people have different interests and therefore different opinions.

mlyle 4y ago
Hey, I've written more C code than anything else and was generally considered pretty competent. > The language is at fault. "Good" programmers do not blame languages for their mistakes. I also know that my time to get something functional in higher level languages is often 10x less, and my probability of having very subtle bugs to hunt is much lower. There's a super-weird tradeoff here. There's all kinds of modern, high-level techniques that improve programmer productivity and reliability of bigger systems.. They convert people who can't be productive C programmers into doing OK work. But they're also slow and a bit opaque in how they work. And it's really easy to run out of performance and have to do exotic things to get them to scale, in which case you have to build bigger systems still and cede a lot of those advantages. Whereas, if you write to the metal, you can get a lot of performance out of a single large computer.

arinlen 4y ago

> My classic C programmer curmudgeon take is that the root of the problem, as with everything else in this industry, is bad software built on top of bad software built on top of bad software... and on it goes. No, not really. Nowadays things are way way better than how they were a decade ago. Nowadays you can get pipelines that build and test on multiple target platforms with a dozen or so lines of code, and things run so well that they became reliable infrastructure integrated with your prod system. Back then you had none of this, and had to pay the salary for a "build engineer" who worked like a wizard stirring a cauldron just to get a single production build out of the door.

blueflow 4y ago
The bad things are still around in your infra even if you manage to never see them because you only see the "dozens lines of code" at the front.
- mrjin 4y ago
  Someone who really buys that "dozens lines of code" will definitely has no idea what kind of complexity it was about.
hinkley 4y ago
I’ve been cultivating this opinion that it’s the other way around. In any other domain, few people use crap tools to make something amazing, and I think it comes down to what you surround yourself with informs what you make. We need better tools if we want better things.
mrjin 4y ago
Oh sure. Can you try to set up ANY CI pipelines to make it more or less working, don't worry about "pipelines that build and test on multiple target platforms" and get back to share with us your experiences?
- allarm 4y ago
  What exactly do you want to hear? Not op, but I’ve been doing it for some time.