4 ms·

> if someone was a decent programmer and willing to invest the time, they could recreate it from scratch without the code This is a stronger claim than the one

> if someone was a decent programmer and willing to invest the time, they could recreate it from scratch without the code This is a stronger claim than the one in the article, which says it's easy for someone to recreate it if they were involved in building it in the first place. 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.

jvanderbot 1y ago
Somehow people are reading a strange, opposite conclusion from this headline. See the "30m to reproduce a days work" argument. What TFA says is that the writing of the code is not the most valuable part of this process, but that does not mean that the code itself is of little value. The fact that writing the code is "easy" once the solution is found does not mean code is of little value! This article shows that code is extremely valuable since it codefies exactly the business logic, design, and hard work of problem solving. It's the map leading through all the challenges to a business solution. It's a shortcut and a working tool. It's the whole point of having expensive software engineers doing difficult design work. Your clean room argument is spot on.
- 6510 1y ago
  Thinking about it, the encoded business logic also becomes hard to change. Perhaps like writing prevented language and stories from evolving. Encoding it might be the final version. I got stuck a few times when the business logic got overly fuzzy. If you have 10 people and 50 small tasks with each task taking between a and b minutes in some strange distribution where b might be 3xa. If task 1 takes more than c minutes task 2 is likely to also take longer while task 3 will be easy. Unless it is full moon then task 2 will take less time and 3 more. On the factory floor the guy to plan this would also know how fast each employee is with each task and that employee 1 has a hangover on Monday, 2 goes to the gym on Thursday and 3 has to babysit before the night shift. But now we are going to have an app to plan this???
ChuckMcM 1y ago
> 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.

jvanderbot 1y ago

Somehow people are reading a strange, opposite conclusion from this headline. See the "30m to reproduce a days work" argument. What TFA says is that the writing of the code is not the most valuable part of this process, but that does not mean that the code itself is of little value. The fact that writing the code is "easy" once the solution is found does not mean code is of little value! This article shows that code is extremely valuable since it codefies exactly the business logic, design, and hard work of problem solving. It's the map leading through all the challenges to a business solution. It's a shortcut and a working tool. It's the whole point of having expensive software engineers doing difficult design work. Your clean room argument is spot on.

6510 1y ago
Thinking about it, the encoded business logic also becomes hard to change. Perhaps like writing prevented language and stories from evolving. Encoding it might be the final version. I got stuck a few times when the business logic got overly fuzzy. If you have 10 people and 50 small tasks with each task taking between a and b minutes in some strange distribution where b might be 3xa. If task 1 takes more than c minutes task 2 is likely to also take longer while task 3 will be easy. Unless it is full moon then task 2 will take less time and 3 more. On the factory floor the guy to plan this would also know how fast each employee is with each task and that employee 1 has a hangover on Monday, 2 goes to the gym on Thursday and 3 has to babysit before the night shift. But now we are going to have an app to plan this???

ChuckMcM 1y ago

> 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.