3 ms·

The spec becomes "don't break important customers code". How could one possibly formalize that?

• chriswarbo 1y ago
  The same way one formalises the implementation (AKA writing code): iteratively, on a best-effort basis, using one's own knowledge and experience, with input and feedback from colleagues and stakeholders, etc.
  • pfdietz 1y ago
    That makes no sense. How do you know what bugs the customer depends on, especially if you don't have access to their code? What's more PBT doesn't depend on having a spec, just on having some properties that hold. So you very possibly didn't have a spec to start with.
    • chriswarbo 1y ago
      > How do you know what bugs the customer depends on, especially if you don't have access to their code? You don't know, but you can ask, you can make educated guesses, etc. As I said, we do this stuff iteratively, on a best-effort basis, using one's own knowledge and experience, with input and feedback from colleagues and stakeholders, etc. That's what most programming is. > What's more PBT doesn't depend on having a spec, just on having some properties that hold I'd say that "having some properties that hold" certainly counts as "some sort of spec (whether formal or informal, written or vibes-based, etc.)". > So you very possibly didn't have a spec to start with. There's always "some sort of spec"; even if it starts as vague as "let's try to make some money using computers".