> It's not true that every piece of software is trivial to copy in a clean-room way, that is, only being able to observe its behaviour and not any implementatio

> It's not true that every piece of software is trivial to copy in a clean-room way, that is, only being able to observe its behaviour and not any implementation details. Ideally, you can change the way you look at this slightly. We can agree that software isn't "trivial" to create. You limit your claim 'observing its behaviour' however and that isn't as precise as we'd like. I'd make the claim this way: "Any piece of software, for which you have both the requirements that define its use and a working example that putatively meets those requirements, is straight forward to re-create from first principles." It is the very definition of the job description that a programmer/engineer can take "requirements" and turn them into "product." That doesn't say anything about how easy or hard that is, just that its the job and people do it all the time. When you have a working example, it both facilitates the engineer's understanding through observation, and provides a test by which the engineer can measure their own progress in meeting the requirements. That allows for iterative development which happens, in my experience, more quickly than when there is not a working example to compare against.