3 ms·

Gigster + https://stamplay.com/ https://stamplay.com/ (Drag and Drop backends) + A front end automator is going to lead to the commoditization of the software d

Gigster + https://stamplay.com/ https://stamplay.com/ (Drag and Drop backends) + A front end automator is going to lead to the commoditization of the software developer.

mattmanser 11y ago
We've done this before, RAD tools in the early 2000s and then a few years after that it was workflows. It doesn't work. One of the skills of being a programmer is to change a business workflow, which are often very vague and even very inefficient and open to interpretation, into a logical workflow. Business people just don't have that skill, so what happens is that you need a bunch of programmers to operate the RAD tools. But the RAD tools have a bunch of restrictions and quirks and don't quite do what is wanted so the programmer is asked if he can just tweak it a bit. And soon those little 'tweaks' are taking longer than building the whole thing from scratch.
- thewarrior 11y ago
  Wow I was just waiting to ask someone who's seen this stuff about this. I'm planning to create some tools ease CRUD workflows. I think my point was not properly conveyed. The goal is not to get the pointy haired boss programming your expense report app. But instead of paying someone with 4 years of experience , you just use a team of people you trained in 3 - 4 months to do most of the screens using such tools . Is that unrealistic ? PS : Yup any code generator needs to have a lot of extensible points so you can change it.
  - mattmanser 11y ago
    I haven't seen any modern ones, but back in the day it was generally a complete and utter disaster. And having extensible points doesn't work. The whole problem is that if they're complicated enough to actually encode a client's project, they're so complicated that they're really just a visual programming language. But that means all the code conditions are hidden in drop-downs and checkboxes. But in reality that's the logic, those options are the code, but you can't easily read the code. If you can't read the code, you can't understand the code. So increasingly no-one has a clue what the system is really doing and you have to test it like crazy. It also makes it very hard to know what has and hasn't changed and even if you can diff it somehow you often can't even understand what the change means. Other problems include the 'extensible points' not being atomic enough, or too atomic, or badly documented, or badly coded, or just plain insanely coded. And if there's a bug you've got to wait for the code generator to be fixed. And finally you are locked in to your vendor. Which becomes a big deal. What happens is that you'll start writing your own code to fix these problems, or edit the auto-generated output somehow (if you're lucky enough to be allowed to) and it'll rapidly turn in to a complete mess that only 1 or 2 people really understand what's going on and it takes a month to do changes that should take a day or two. ORMs are the closest we get to auto-code generation and there's a reason we stop there. We learnt from bitter experience. And even they can be dangerous in the wrong hands. Still, I guess we've got to try again every now and then, one day someone might nail it.

Gigster + https://stamplay.com/ https://stamplay.com/ (Drag and Drop backends) + A front end automator is going to lead to the commoditization of the software developer.

mattmanser 11y ago

We've done this before, RAD tools in the early 2000s and then a few years after that it was workflows. It doesn't work. One of the skills of being a programmer is to change a business workflow, which are often very vague and even very inefficient and open to interpretation, into a logical workflow. Business people just don't have that skill, so what happens is that you need a bunch of programmers to operate the RAD tools. But the RAD tools have a bunch of restrictions and quirks and don't quite do what is wanted so the programmer is asked if he can just tweak it a bit. And soon those little 'tweaks' are taking longer than building the whole thing from scratch.

thewarrior 11y ago
Wow I was just waiting to ask someone who's seen this stuff about this. I'm planning to create some tools ease CRUD workflows. I think my point was not properly conveyed. The goal is not to get the pointy haired boss programming your expense report app. But instead of paying someone with 4 years of experience , you just use a team of people you trained in 3 - 4 months to do most of the screens using such tools . Is that unrealistic ? PS : Yup any code generator needs to have a lot of extensible points so you can change it.
- mattmanser 11y ago
  I haven't seen any modern ones, but back in the day it was generally a complete and utter disaster. And having extensible points doesn't work. The whole problem is that if they're complicated enough to actually encode a client's project, they're so complicated that they're really just a visual programming language. But that means all the code conditions are hidden in drop-downs and checkboxes. But in reality that's the logic, those options are the code, but you can't easily read the code. If you can't read the code, you can't understand the code. So increasingly no-one has a clue what the system is really doing and you have to test it like crazy. It also makes it very hard to know what has and hasn't changed and even if you can diff it somehow you often can't even understand what the change means. Other problems include the 'extensible points' not being atomic enough, or too atomic, or badly documented, or badly coded, or just plain insanely coded. And if there's a bug you've got to wait for the code generator to be fixed. And finally you are locked in to your vendor. Which becomes a big deal. What happens is that you'll start writing your own code to fix these problems, or edit the auto-generated output somehow (if you're lucky enough to be allowed to) and it'll rapidly turn in to a complete mess that only 1 or 2 people really understand what's going on and it takes a month to do changes that should take a day or two. ORMs are the closest we get to auto-code generation and there's a reason we stop there. We learnt from bitter experience. And even they can be dangerous in the wrong hands. Still, I guess we've got to try again every now and then, one day someone might nail it.