3 ms·

Even if you assume programmers are replaceable code monkeys, you seem to be ignoring a large portion of what their responsibilities involve: fixing bugs, writin

by lhorie 8y ago

Even if you assume programmers are replaceable code monkeys, you seem to be ignoring a large portion of what their responsibilities involve: fixing bugs, writing tests, integrating 3rd party libraries, managing version control, etc. Simply changing from programming language to one with a different target audience isn't going to make those responsibilities go away; you'd just be pushing them to people who don't necssarily have the skillset to translate a requirement to the highly strict format that a programming language provides. Your idea is analogous to saying "if only I created an amazing enough 3D printer, architects would no longer require engineers and construction workers to erect a building". But this ignores the fact that an architect doesn't know the first thing about bylaws, material strength, logistics, rain, etc. In reality, now the architect would be responsible for having the expertise of one or more other prefessions.

MuffinFlavored 8y ago
> fixing bugs I like this counter argument because as a developer, it stinks tracking down bugs. In a perfect world, if the English to code compiler worked pretty well, couldn't the blame of bugs be moved to the business analysts writing the requirements? > writing tests if the code does exactly what the business requirements say, why are tests needed? > integrating 3rd party libraries a huge portion of programming to me is "calling a function or an endpoint of a 3rd party library". to me, that could very easily fit into the plain English format I'm proposing for this "technology language"
- 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?

by lhorie 8y ago

MuffinFlavored 8y ago

> fixing bugs I like this counter argument because as a developer, it stinks tracking down bugs. In a perfect world, if the English to code compiler worked pretty well, couldn't the blame of bugs be moved to the business analysts writing the requirements? > writing tests if the code does exactly what the business requirements say, why are tests needed? > integrating 3rd party libraries a huge portion of programming to me is "calling a function or an endpoint of a 3rd party library". to me, that could very easily fit into the plain English format I'm proposing for this "technology language"

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?