Here's my "pro-stagnation" argument: stagnation and stability are pretty much the same thing. There's a lot of infrastructure that we take for granted because it always works (water purification and distribution, bridges and roads, electrical generation and transmission, automobile engines, the quality of gasoline, the safety of food, etc). You trust that these things will work the way you expect, because they don't change very quickly. Is that stagnation or stability?
So I don't know about you, but I live in America where roads, electrical generation and transmission, water purification, and bridges are all in subpar shape.
That's super broad and I think there are complex reasons why each of these has failed, but it's pretty clear that stagnation hasn't helped and has probably actively caused harm by letting incompetence become too common in these areas.
Code that changes introduces new bugs, new bugs can be new security issues. A lower velocity would hopefully mean less changes but higher quality, more thoroughly tested changes.
Let's start by fixing the language. It's not stagnation, it's predictability.
Civil and mechanical engineering are not static fields. They come up with new materials, new methods, new ideas. They have tooling to understand the impact of a proposed change and standard ways to test and validate things. It is much easier to predict how long it will take to both design and build things. These are all good things.
We would all benefit from fewer cryptoAI startups and frameworks of the week and more robust toolchains tested and evolved over decades.
Let me hear your pro-stagnation argument
Here's my "pro-stagnation" argument: stagnation and stability are pretty much the same thing. There's a lot of infrastructure that we take for granted because it always works (water purification and distribution, bridges and roads, electrical generation and transmission, automobile engines, the quality of gasoline, the safety of food, etc). You trust that these things will work the way you expect, because they don't change very quickly. Is that stagnation or stability?
So I don't know about you, but I live in America where roads, electrical generation and transmission, water purification, and bridges are all in subpar shape.
That's super broad and I think there are complex reasons why each of these has failed, but it's pretty clear that stagnation hasn't helped and has probably actively caused harm by letting incompetence become too common in these areas.
3 replies →
Code that changes introduces new bugs, new bugs can be new security issues. A lower velocity would hopefully mean less changes but higher quality, more thoroughly tested changes.
This is the best argument anyone has given in this thread.
Strongly agree that fewer changes equals fewer bugs, it just comes down to trading that off with shipping value in your product.
Let's start by fixing the language. It's not stagnation, it's predictability.
Civil and mechanical engineering are not static fields. They come up with new materials, new methods, new ideas. They have tooling to understand the impact of a proposed change and standard ways to test and validate things. It is much easier to predict how long it will take to both design and build things. These are all good things.
We would all benefit from fewer cryptoAI startups and frameworks of the week and more robust toolchains tested and evolved over decades.
Why do you think such wrong things about civil and mechanical engineering.
Tell me about all the on time and under budget civil/mechanical engineering projects that are happening.
Do you think that just because they have physics to lean on that they can just like press solve and have accurate estimates spit out?
Edit: I totally agree that more long-lived battle tested software toolchains and libraries would be great though
8 replies →