Comment on How does code that's meant to fix one bug break other features?

josephc@lemmy.ml ⁨3⁩ ⁨days⁩ ago

Imagine you’re writing a book. In this book you need to be perfectly consistent and coherent because the people reading it are so incredibly literal that if there’s ambiguity or inconsistency they will run into your home and defecate on your carpet.

Short stories are easy enough. There’s only a character or two and you can generally remember what they’re wearing and what they said, but as the stores get longer you start to work yourself into corners and lose track of what you said in the previous chapters.

Let’s say you reach a scene where the main character needs to hop on a train. You write a scene where they purchase a ticket. But wait, a few chapters ago you said they got mugged! So you decide to cut that scene. Now they can pay for a ticket, but the scene where they said they got mugged is wrong and the scene where they said they can’t pay their bill doesn’t work!

Computers read instructions and interpret them. They follow orders. Programming raw hardware is tricky, so we add abstractions to make it easier. Collectively we agree, “we’ll put a return pointer here, then push these instructions here and set the program counter here” as the way we call subroutines or send data or something else. If there’s ambiguity in the specification then two people might build two different programs which they both expect to work. One of them will fail. If there are ten people implementing things with an API, perhaps all ten will fail.

Hyrem’s Law says any observable behavior will eventually become part of a workflow.

source
Sort:hotnewtop