| ▲ | skydhash a day ago | |||||||
> If I commission a part specified as 10.00 ± 0.01 mm, I can verify it with a calibrated micrometer But there is someone that needs to design that part, specify the material needed and a few other things. The actual verification is fast because someone has compiled the list of checks. And compiling that list of checks is hard work. In other words, where '10.00 ± 0.01 mm' comes from is very important. That's why people says typing code is not the issue. Code is merely the medium of '10.00 ± 0.01 mm' definition. The actual product is the software process. And that is already a black box as only a few developers goes on to learn computer architecture and instruction sets. Instead we deal with high level instructions like map, filter, and print. Which are the tools to say '10.00 ± 0.01 mm' instead of "this length" while demonstrating with fingers. And yes for programmers, most specs are as imprecise as the latter form. | ||||||||
| ▲ | theshrike79 18 hours ago | parent [-] | |||||||
No, the code isn't what defines it. It's the tests and specs around it. Code should never be the only source of truth. Another shitty analogy: baking. Saying "code is the medium of the definition" is like saying "the cake is the medium of the recipe". So anyone wanting to make the cake or change how it's made should just dive into the cake and start analysing it. That's why we have recipes, and even they can be modified as long as the exepectation is met: It has to be sweet, soft, covered in something white and must have strawberries inside. Code should be the same, I should be able to toss the whole codebase in the trash and regenerate it from the tests and written specifications. If I can't there's something wrong with the process. | ||||||||
| ||||||||