4 ms·

> Software doesn’t stay solved. Every solution you write starts to rot the moment it exists. I don't really agree with this. Yes, it gets outdated quickly and

by XCSme 1y ago

> Software doesn’t stay solved. Every solution you write starts to rot the moment it exists. I don't really agree with this. Yes, it gets outdated quickly and breaks often if you build it in such a way that it relies on many external services. Stuff like relying on "number-is-odd" NPM package instead of copy-pasting the code or implementing it yourself. The more dependencies you have, the more likely it will break. If your software works locally, without requiring an internet connection, it will work almost forever. Now, if you want to keep developing the software and build it over a long period, the secret is to always keep all dependencies up-to-date. Is there a ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be.

chamomeal 1y ago
That sorta supports the point the article was making though: > ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be. Is, to me, almost the same sentence as > Every solution you write starts to rot the moment it exists
- XCSme 1y ago
  I mentioned updating is only necessary if you plan to keep developing the software. If you build it once, and the existing functionality is enough (no plans to add extra features ever again), then you can remove all external dependencies and make it self-contained, in which case it will be very unlikely to break in any way. As for the security aspects of not updating, with the proper setup, firewall rules and data sanitization, it should be as secure 10 years later as any recently developed software.
- 0x1ceb00da 1y ago
  > Every solution you write starts to rot the moment it exists Not if you work on temple os.
ajuc 1y ago
I remember when Turbo Pascal 7.0 programs started failing with Division by 0 error cause Turbo Pascal runtime does calibration loop at the start to calculate how many no-ops to sleep for 1 millisecond. So - your HelloWorld written 10 years ago suddenly stopped working after CPU you run it on got too fast.
- XCSme 1y ago
  Yes, if you change hardware, the software can break (a lot less often now than before though, as hardware changes are a negligible and they usually think about backwards compatibility).
  - toyg 1y ago
    > a lot less often now than before though Someone is not familiar with iOS/macOS/Android, where stuff breaks every. effing. year. Windows is the exception, nowadays.
  - ajuc 1y ago
    I'm not sure if it's more or less often now, but over decades almost everything breaks one way or another. Even if your code, OS and hardware had no bugs and was designed perfectly and you keep the same hardware to run you code forever - there's layers under the hardware - the reality outside the computer. You have written perfectly secure website. Then quantum computers happen. Countries are created and fall apart. People switch writing systems and currencies. Calendars get updated. Your code might technically work after 100 years, but with almost 100% probability it won't be useful for anything.
    - XCSme 1y ago
      That's most probable to happen, but there are still example of hardrware/devices created many years ago that function exactly the same. If you take a Tamagotchi device from 30 years ago, it will likely still work as well as it did when it was released.
- int_19h 1y ago
Phlebsy 1y ago
To me the point of the saying is more that the assumptions and environment that the software was written with are almost always going to change. Meaning the business and requirements rather than the technical implementation choices. Software doesn't exist in a vacuum, but rather to solve a certain set of business requirements that have the potential to shift out from under you depending on the industry, legislation, and your leadership. The things that you have negligible control or foresight over, rather than knowing that there's going to be another major framework update next quarter. There are certainly horizontal slices of every stack that can be written to remain stable regardless of the direction the business takes, but those are rarely the revenue drivers that the business cares about beyond how much they have the potential to cause instability.

by XCSme 1y ago

chamomeal 1y ago

That sorta supports the point the article was making though: > ExternalLibrary V2 just released? Instead of postponing the migration, update your code and migrate ASAP. The later you do it, the harder the migration will be. Is, to me, almost the same sentence as > Every solution you write starts to rot the moment it exists

XCSme 1y ago
I mentioned updating is only necessary if you plan to keep developing the software. If you build it once, and the existing functionality is enough (no plans to add extra features ever again), then you can remove all external dependencies and make it self-contained, in which case it will be very unlikely to break in any way. As for the security aspects of not updating, with the proper setup, firewall rules and data sanitization, it should be as secure 10 years later as any recently developed software.
0x1ceb00da 1y ago
> Every solution you write starts to rot the moment it exists Not if you work on temple os.

ajuc 1y ago

I remember when Turbo Pascal 7.0 programs started failing with Division by 0 error cause Turbo Pascal runtime does calibration loop at the start to calculate how many no-ops to sleep for 1 millisecond. So - your HelloWorld written 10 years ago suddenly stopped working after CPU you run it on got too fast.

XCSme 1y ago
Yes, if you change hardware, the software can break (a lot less often now than before though, as hardware changes are a negligible and they usually think about backwards compatibility).
- toyg 1y ago
  > a lot less often now than before though Someone is not familiar with iOS/macOS/Android, where stuff breaks every. effing. year. Windows is the exception, nowadays.
- ajuc 1y ago
  I'm not sure if it's more or less often now, but over decades almost everything breaks one way or another. Even if your code, OS and hardware had no bugs and was designed perfectly and you keep the same hardware to run you code forever - there's layers under the hardware - the reality outside the computer. You have written perfectly secure website. Then quantum computers happen. Countries are created and fall apart. People switch writing systems and currencies. Calendars get updated. Your code might technically work after 100 years, but with almost 100% probability it won't be useful for anything.
  - XCSme 1y ago
    That's most probable to happen, but there are still example of hardrware/devices created many years ago that function exactly the same. If you take a Tamagotchi device from 30 years ago, it will likely still work as well as it did when it was released.
int_19h 1y ago

Phlebsy 1y ago

To me the point of the saying is more that the assumptions and environment that the software was written with are almost always going to change. Meaning the business and requirements rather than the technical implementation choices. Software doesn't exist in a vacuum, but rather to solve a certain set of business requirements that have the potential to shift out from under you depending on the industry, legislation, and your leadership. The things that you have negligible control or foresight over, rather than knowing that there's going to be another major framework update next quarter. There are certainly horizontal slices of every stack that can be written to remain stable regardless of the direction the business takes, but those are rarely the revenue drivers that the business cares about beyond how much they have the potential to cause instability.