3 ms·

> Its always decreasing because entropy builds up on longer projects. Its simply the fact of life, not particularly specific to coding. I don’t know much physi

> Its always decreasing because entropy builds up on longer projects. Its simply the fact of life, not particularly specific to coding. I don’t know much physics, but this word-soup about entropy is mistaken, isn’t it? Because something something about closed systems vs open systems and putting energy into systems (eg, people working on the codebase)? > The best you can do is to have automatic tests, lots of them, and make them work as intended (good tests are very hard to make). I’m not sure what “best” means here, but there are other tools for improving software quality beyond tests, including and in particular formal methods. > Those [tests] make refactoring possible and make specific quality guaranties. What quality guarantees do tests make? That the build passes the test suite?

majkinetor 5y ago
You are trolling here aren't you ? > Because something something about closed systems vs open systems and putting energy into systems (eg, people working on the codebase)? Did you ever lead a project that spans at least half decade? And is this a coherent thought or something something whatever? > I’m not sure what “best” means here, but there are other tools for improving software quality beyond tests, including and in particular formal methods. There are other tools, but the one that makes refactoring possible is the best you can do regarding OP question. If you have a bad quality code, you need to refactor, no? You might want to have some other tools like superb docs, formal proofs etc. but those do next to 0 when you need to refactor and guarantee that you didn't break hell. > What quality guarantees do tests make? That the build passes the test suite? Notice the part about "good tests" which are "very hard" to do.
- burrows 5y ago
  My first comment was specifically about the invocation of “entropy”, which I believe is just confusing nonsense. And as I said I don’t have the requisite background to really make the point, was hoping for some goodwill and assistance perhaps. I’ll retract my comment about formal methods since I’ve never actually used them in a refactor. And I agree that tests make refactoring easier. But none of this demonstrates for me that tests are the “best” tool for facilitating a refactor. And so, what specific quality guarantees do good tests make?
  - majkinetor 5y ago
    Lets check out wikipedia: Entropy is a scientific concept as well as a measurable physical property that is most commonly associated with a state of disorder, randomness, or uncertainty What is your claim, that disorder, randomness and uncertainty DO NOT build up with time? :) > And I agree that tests make refactoring easier. They don't make it easier. They make it POSSIBLE. > And so, what specific quality guarantees do good tests make? Good tests cover all critical sections of functional specification (what is deemed critical depends on project). If you have functional rules x, y and z somewhere there, there need to be bunch of tests for x, y and z somewhere, ideally fuzzy, fast and without blank database. This is all very much basic IT stuff for long time, particularly nowadays when software needs to run not only in your basement but on every conservable device and number of different contexts! No offense, but you seem new in this business, and your aggression doesn't help at all.
    - burrows 5y ago
      > What is your claim, that disorder, randomness and uncertainty DO NOT build up with time? It depends on the system. Claiming that disorder builds up in all systems is false, afaik. From a Google search: Entropy increases in a closed system. In open systems, the entropy is kept low, or decreases Are you claiming that codebases are closed systems? > They don't make them easier. They make them POSSIBLE. Are you arguing about the definition of “easier” or just trying to rhetorically emphasize the impact of tests on refactoring? Would you agree if I said tests make refactoring A LOT easier? Seems like we both agree that we’d rather refactor a system with tests than without (all else the same). > Good tests cover all critical sections of functional specification (what is deemed critical depends on project). If you have functional rules x, y and z somewhere there, there need to be bunch of tests for x, y and z somewhere, ideally fuzzy, fast and without blank database. You’ve told me what parts of the code you want to test, but not what guarantees the tests make. > No offense, but you seem new in this business, and your aggression doesn't help at all. You’re right I’m new. Thanks for your patience.
    - kaba0 5y ago
      The topmost claim was that software quality degrades over time, as entropy must increase. Both of these claims are false, as the topmost commenter did actually say correctly - entropy only grows globally, but it is possibly to decrease it locally at the expense of some larger increase somewhere else (think of a fridge - it decreases the randomness of molecules inside (cooler) by heating the outside). If we accept this analogy, then with enough care, a software project can improve in quality (paying off technical debt for example, or extensive code reviews by experts). But even letting go of this possibly flawed analogy, while there is a tendency of entropy-build up, very easily observable in my home folder, there exist software projects that do improve in quality over time.

majkinetor 5y ago

You are trolling here aren't you ? > Because something something about closed systems vs open systems and putting energy into systems (eg, people working on the codebase)? Did you ever lead a project that spans at least half decade? And is this a coherent thought or something something whatever? > I’m not sure what “best” means here, but there are other tools for improving software quality beyond tests, including and in particular formal methods. There are other tools, but the one that makes refactoring possible is the best you can do regarding OP question. If you have a bad quality code, you need to refactor, no? You might want to have some other tools like superb docs, formal proofs etc. but those do next to 0 when you need to refactor and guarantee that you didn't break hell. > What quality guarantees do tests make? That the build passes the test suite? Notice the part about "good tests" which are "very hard" to do.

burrows 5y ago
My first comment was specifically about the invocation of “entropy”, which I believe is just confusing nonsense. And as I said I don’t have the requisite background to really make the point, was hoping for some goodwill and assistance perhaps. I’ll retract my comment about formal methods since I’ve never actually used them in a refactor. And I agree that tests make refactoring easier. But none of this demonstrates for me that tests are the “best” tool for facilitating a refactor. And so, what specific quality guarantees do good tests make?
- majkinetor 5y ago
  Lets check out wikipedia: Entropy is a scientific concept as well as a measurable physical property that is most commonly associated with a state of disorder, randomness, or uncertainty What is your claim, that disorder, randomness and uncertainty DO NOT build up with time? :) > And I agree that tests make refactoring easier. They don't make it easier. They make it POSSIBLE. > And so, what specific quality guarantees do good tests make? Good tests cover all critical sections of functional specification (what is deemed critical depends on project). If you have functional rules x, y and z somewhere there, there need to be bunch of tests for x, y and z somewhere, ideally fuzzy, fast and without blank database. This is all very much basic IT stuff for long time, particularly nowadays when software needs to run not only in your basement but on every conservable device and number of different contexts! No offense, but you seem new in this business, and your aggression doesn't help at all.
  - burrows 5y ago
    > What is your claim, that disorder, randomness and uncertainty DO NOT build up with time? It depends on the system. Claiming that disorder builds up in all systems is false, afaik. From a Google search: Entropy increases in a closed system. In open systems, the entropy is kept low, or decreases Are you claiming that codebases are closed systems? > They don't make them easier. They make them POSSIBLE. Are you arguing about the definition of “easier” or just trying to rhetorically emphasize the impact of tests on refactoring? Would you agree if I said tests make refactoring A LOT easier? Seems like we both agree that we’d rather refactor a system with tests than without (all else the same). > Good tests cover all critical sections of functional specification (what is deemed critical depends on project). If you have functional rules x, y and z somewhere there, there need to be bunch of tests for x, y and z somewhere, ideally fuzzy, fast and without blank database. You’ve told me what parts of the code you want to test, but not what guarantees the tests make. > No offense, but you seem new in this business, and your aggression doesn't help at all. You’re right I’m new. Thanks for your patience.
  - kaba0 5y ago
    The topmost claim was that software quality degrades over time, as entropy must increase. Both of these claims are false, as the topmost commenter did actually say correctly - entropy only grows globally, but it is possibly to decrease it locally at the expense of some larger increase somewhere else (think of a fridge - it decreases the randomness of molecules inside (cooler) by heating the outside). If we accept this analogy, then with enough care, a software project can improve in quality (paying off technical debt for example, or extensive code reviews by experts). But even letting go of this possibly flawed analogy, while there is a tendency of entropy-build up, very easily observable in my home folder, there exist software projects that do improve in quality over time.