4 ms·

Code is alive and there’s typically always something to do: adding tests, removing bugs, or simply paying back technical debt. If you go a full year without any

Code is alive and there’s typically always something to do: adding tests, removing bugs, or simply paying back technical debt. If you go a full year without any releasable changes, chances are the project has been abandoned.

lanstin 5y ago
My goal is to write servers that get uptimes more than a year. Like the old saying, peefection is reached not shem there is nothing left to add but nothing left to delete.
- toyg 5y ago
  > peefection Unrelated, but your typo made me think that "Peerfection" would be a great name for a P2P program.
blktiger 5y ago
Not only that, but no release in the last year is likely to be missing fixes for security issues on any sufficiently complicated project.
watwut 5y ago
Why would you paid back technical debt on something where you don't intend to add features into or don't have serious bugs? This idea that it must be changing forever is literally why you can't have simple done tools. Cause they will be considered abandoned once they do that one thing.
- ironmagma 5y ago
  So that changes can be more readily introduced when they need to be. When the next CVE comes out, you want to be able to respond to it quickly and produce a fix. No one said the interface or functionality has to be changing forever; as I said, work includes testing and refactors, and that includes removing code. Or just fixing known bugs. I don’t know many open source projects with zero bugs, do you?
  - watwut 5y ago
    So, you will refactor and add tests to a small library forever? It just, does not make sense.
    - ironmagma 5y ago
      If it’s a useful library, you want to be more and more certain it doesn’t have bugs, so yes, you keep adding tests. Maybe you stop when it’s clear that the library is perfect. But when has any project reached that state? If it’s too small though, it’s probably not that useful and this doesn’t apply. It doesn’t really make sense to care about whether it was abandoned, either, because it will be so small that it doesn’t have any onboarding time and anyone can pick it up at any time.

lanstin 5y ago

My goal is to write servers that get uptimes more than a year. Like the old saying, peefection is reached not shem there is nothing left to add but nothing left to delete.

toyg 5y ago
> peefection Unrelated, but your typo made me think that "Peerfection" would be a great name for a P2P program.

blktiger 5y ago

Not only that, but no release in the last year is likely to be missing fixes for security issues on any sufficiently complicated project.

watwut 5y ago

Why would you paid back technical debt on something where you don't intend to add features into or don't have serious bugs? This idea that it must be changing forever is literally why you can't have simple done tools. Cause they will be considered abandoned once they do that one thing.

ironmagma 5y ago
So that changes can be more readily introduced when they need to be. When the next CVE comes out, you want to be able to respond to it quickly and produce a fix. No one said the interface or functionality has to be changing forever; as I said, work includes testing and refactors, and that includes removing code. Or just fixing known bugs. I don’t know many open source projects with zero bugs, do you?
- watwut 5y ago
  So, you will refactor and add tests to a small library forever? It just, does not make sense.
  - ironmagma 5y ago
    If it’s a useful library, you want to be more and more certain it doesn’t have bugs, so yes, you keep adding tests. Maybe you stop when it’s clear that the library is perfect. But when has any project reached that state? If it’s too small though, it’s probably not that useful and this doesn’t apply. It doesn’t really make sense to care about whether it was abandoned, either, because it will be so small that it doesn’t have any onboarding time and anyone can pick it up at any time.