3 ms·
> if the English to code compiler worked pretty well, "In theory, theory and practice are the same. In practice, they are not" In practice, the so called "eng
by lhorie 8y ago
> if the English to code compiler worked pretty well,
"In theory, theory and practice are the same. In practice, they are not"
In practice, the so called "english to code compiler" is an abstraction, which means more code, which means more bugs, abstraction leaks, complexity, etc.
> couldn't the blame of bugs be moved to the business analysts writing the requirements?
Shifting blame is just avoiding responsibility. Someone still has to be responsible. If what you're proposing is that the BA has to shoulder the expertise of formulating requirements, implementing them, testing them, etc, at some point an organization with half a brain will just hire different people for each responsibility.
> if the code does exactly what the business requirements say
People write tests precisely because code doesn't always do exactly what the requirements say (especially over time, as requirements change and technical debt mounts).
> that could very easily fit into the plain English
This is the old story of "make me a toast". Well, actually, that means opening the bread bag, getting a slice of bread out, putting it in the toaster, making sure it is plugged in, tweaking the timer knob, starting the toaster, waiting, taking the toast out, putting it on a plate, etc (never mind you have to actually buy the bread if you don't have any on hand or wash the dishes if you don't have a clean plate). Similarly: "make me carousel". Well, actually...
- MuffinFlavored 8y ago> to shoulder the expertise of formulating requirements, implementing them, testing them, etc, at some point an organization with half a brain will just hire different people for each responsibility. So, in a perfect world, formulating the requirements would be implementing them with this "compiler/language/abstraction layer". Does that help make it any clearer?