7 ms·

Programmerless programming is just a mirage

29 points by edw519 16y ago

pessimizer 16y ago
In my experience(YMMV) with trying to use BPMN to make inroads into automating workflows at a small financial authority, I had to reduce it to an extremely small subset even just to get business stakeholders to look at the models. The only ones who were assigned to actually help me create the models were the most-spareable, least-knowledgeable people in the organization who pretty much only used a subset reduced to ANDs, ORs, and XORs, and after months, still didn't consistently understand the difference between ORs and XORs. The ability (or even the earnest attempt) to use the symbols correctly had absolutely no relation to the enthusiasm any individual showed towards using heavily marketed tools promising automated execution. So basically, I was assigned the least knowledgeable people to work on models, and I had to spend an order of magnitude more time redoing their work than they spent doing it. In the end we had a big beautiful graph that no one could verify was accurate in any way except me by describing sections in plain English during the 20 minute meetings I could sometimes wrangle out of the people who knew the business side well enough to give me a plain English answer that was interpreted by me and added to the giant unverifiable graph. Really a horrible experience all around. And at the beginning of the project, I really thought BPMN looked nice. Of course, I looked at it like a programmer:)
- jimbokun 16y ago
  How did they express their models before the BPMN tools?
jdietrich 16y ago
Programming isn't about knowing syntax, it's about understanding abstraction. Some people can solve FizzBuzz, some people can't. If you can't abstract then you can't program, regardless of the tools. That's the problem we need to solve, not simplifying the interface. I've seen secretaries build beautifully elegant systems with Excel Macros and I've seen CS graduates from good schools fail to build even the simplest of programs. I expect most people here have seen similar extremes. A large proportion of CS majors never learn to program. Until we figure out why, and how to change that, 'programmerless programming' is doomed.
- Groxx 16y ago
  The place I work recently encountered someone who couldn't solve FizzBuzz, for the first time. I think a little bit of them died that day - they were looking around with a shocked expression for quite a while.
- danilocampos 16y ago
  I hadn't heard of FizzBuzz, but tried it out a moment ago. How is possible for someone with a rudimentary understanding of programming to be unable to solve this in a couple of minutes?
  - jrockway 16y ago
    It's not. The problem with the world of professional programming is that there are a lot of people claiming to be programmers that aren't. The reason why people can code-monkey their PHP scripts but not solve FizzBuzz is because of an iterative process. When you are hacking some web page, you just change stuff until it works. You try again and again and again and eventually you're right. With FizzBuzz, you have to think about a couple things before you answer. It's so simple that you have to get it right the first time; you're supposed to think, then program. But most people are not in the habit of thinking, and just skip right to the press buttons while staring at the blinky cursor stage. Then they fail the FizzBuzz interview.
    - raganwald 16y ago
      Thank you, this is very insightful, this idea that some problems are amenable to just trying things and some problems require thought before starting.
  - Groxx 16y ago
    The one I was referring to (and apparently others, though they 'solved' it) didn't know about modulo. Which would certainly make it harder, though it's ridiculously fundamental. They worked for about 20 minutes writing out something to do with a 101-element array and decimal arithmetic to initialize it (without using ceil / floor to compare, thus mimicking a mod function) before they admitted they were stuck. This applicant was a graduate of some fairly high ranked university, though I don't know which one. They can come from anywhere.
devmonk 16y ago
The thing that I find really strange is that development is becoming more about putting the pieces together and writing code to make small changes than it is about really writing much code. Between the many available jars, gems, plugins, etc. out there, many things we need have been written. While I know some semblance of a programmer will be needed to get things done for some years to come. But at some point, instead of craftsmen, we're going to have more "McDonald's" programmers that are following the book, throwing the code into a microwave, and bagging it.
- gruseom 16y ago
  This is certainly a trend. But it will never take over the entire programming world, and there will always be a supply of more challenging and interesting work for those of us who crave it. In my optimistic moments, I think maybe this trend is a solution for the fundamental problem of the software industry, that the demand for programmers has always by an order of magnitude exceeded the demographic supply of people who can really do it.
  - Vivtek 16y ago
    It's not a trend. It's the very nature of computer science. COBOL was a way to program computers directly in something like English, without the need for a programmer to write all that machine code and manage the registers. SQL was a way to program computers directly by describing the data you wanted to retrieve, without the need for a programmer to write the COBOL to hit your VSAM tables. There will always be programming work, because there will always be a need to formalize knowledge and processes - I believe it will eventually be automated, but that is an NLP-equivalent problem. It's not going to be solved with today's technology. Perhaps a better take-away would be that such "non-programming programming" platforms should still be written by people who understand the processes we've developed to ensure more workable software, things like version control and unit testing. It's not like these couldn't be integrated with this sort of easy-to-access domain-specific tool that permits technically less savvy people to codify some of their own knowledge.
    - 16y ago
gruseom 16y ago
I agree with the analysis and have come to the same conclusions over the years. Still, there's one huge exception: the spreadsheet. That's the one UI that has been massively successful at letting non-programmers program without knowing they're doing it.
regularfry 16y ago
It's very, very tempting to believe that this is true. However, the example picked - business process management - is such a spectacularly badly tooled, over-promising and under-delivering area that I don't think it's possible to draw conclusions that wide from it. BPM has the potential to support some really agile business styles, but I just don't see (or hear - maybe I just haven't got my ear close enough to the ground) that it's being applied to the right businesses at the right time. The best time is right at the start, which means that the tools need to be small, simple and agile, not bloated and overweight. Everyone deals in abstraction to some degree; business owners and managers are no different. We just need to find a way to map their abstractions to ours in a way that's easier for them to understand. I don't know what that would look like, but I also don't expect it to be a dumbing-down. I do know that BPEL and BPMN aren't it.
motters 16y ago
I expect that in future there will be more automated programming, based upon a vague description of the problem. However, I've seen very little progress made in this domain other than a few applications of genetic programming and the use of Wizards or UML templates. In the early days of my software career I encountered plenty of situations which had resulted from the use of Wizards to generate database applications by non programmers. The results were always quite disastrous.
utoku 16y ago
I think one of the big mistakes is the assumption that one can get away from symbols and language by using gadgets, windows, or flowcharts. Even if you succeed at some level, you end up with a different language, which still requires programming and abstraction skills, but the language usually ends up being inefficient. I find that written symbols are very efficient. At least, as long as I have this keyboard in front of me.
InclinedPlane 16y ago
No matter how easy you make programming there will always be an irreducible complexity in creating a tool for a task. What form that task takes and the difficulty involved may change but ultimately there is a kernel of "programmingness" that you won't be able to get rid of. More so, making easy projects trivial and making hard tasks easy merely makes previously impossible tasks possible, so there will always be developers pushing the envelope programming at the maximum level of difficulty that humans are capable of. No different than any other skill in history.

29 points by edw519 16y ago

In my experience(YMMV) with trying to use BPMN to make inroads into automating workflows at a small financial authority, I had to reduce it to an extremely small subset even just to get business stakeholders to look at the models. The only ones who were assigned to actually help me create the models were the most-spareable, least-knowledgeable people in the organization who pretty much only used a subset reduced to ANDs, ORs, and XORs, and after months, still didn't consistently understand the difference between ORs and XORs. The ability (or even the earnest attempt) to use the symbols correctly had absolutely no relation to the enthusiasm any individual showed towards using heavily marketed tools promising automated execution. So basically, I was assigned the least knowledgeable people to work on models, and I had to spend an order of magnitude more time redoing their work than they spent doing it. In the end we had a big beautiful graph that no one could verify was accurate in any way except me by describing sections in plain English during the 20 minute meetings I could sometimes wrangle out of the people who knew the business side well enough to give me a plain English answer that was interpreted by me and added to the giant unverifiable graph. Really a horrible experience all around. And at the beginning of the project, I really thought BPMN looked nice. Of course, I looked at it like a programmer:)

jimbokun 16y ago
How did they express their models before the BPMN tools?

jdietrich 16y ago

Programming isn't about knowing syntax, it's about understanding abstraction. Some people can solve FizzBuzz, some people can't. If you can't abstract then you can't program, regardless of the tools. That's the problem we need to solve, not simplifying the interface. I've seen secretaries build beautifully elegant systems with Excel Macros and I've seen CS graduates from good schools fail to build even the simplest of programs. I expect most people here have seen similar extremes. A large proportion of CS majors never learn to program. Until we figure out why, and how to change that, 'programmerless programming' is doomed.

Groxx 16y ago
The place I work recently encountered someone who couldn't solve FizzBuzz, for the first time. I think a little bit of them died that day - they were looking around with a shocked expression for quite a while.
danilocampos 16y ago
I hadn't heard of FizzBuzz, but tried it out a moment ago. How is possible for someone with a rudimentary understanding of programming to be unable to solve this in a couple of minutes?
- jrockway 16y ago
  It's not. The problem with the world of professional programming is that there are a lot of people claiming to be programmers that aren't. The reason why people can code-monkey their PHP scripts but not solve FizzBuzz is because of an iterative process. When you are hacking some web page, you just change stuff until it works. You try again and again and again and eventually you're right. With FizzBuzz, you have to think about a couple things before you answer. It's so simple that you have to get it right the first time; you're supposed to think, then program. But most people are not in the habit of thinking, and just skip right to the press buttons while staring at the blinky cursor stage. Then they fail the FizzBuzz interview.
  - raganwald 16y ago
    Thank you, this is very insightful, this idea that some problems are amenable to just trying things and some problems require thought before starting.
- Groxx 16y ago
  The one I was referring to (and apparently others, though they 'solved' it) didn't know about modulo. Which would certainly make it harder, though it's ridiculously fundamental. They worked for about 20 minutes writing out something to do with a 101-element array and decimal arithmetic to initialize it (without using ceil / floor to compare, thus mimicking a mod function) before they admitted they were stuck. This applicant was a graduate of some fairly high ranked university, though I don't know which one. They can come from anywhere.

devmonk 16y ago

The thing that I find really strange is that development is becoming more about putting the pieces together and writing code to make small changes than it is about really writing much code. Between the many available jars, gems, plugins, etc. out there, many things we need have been written. While I know some semblance of a programmer will be needed to get things done for some years to come. But at some point, instead of craftsmen, we're going to have more "McDonald's" programmers that are following the book, throwing the code into a microwave, and bagging it.

gruseom 16y ago
This is certainly a trend. But it will never take over the entire programming world, and there will always be a supply of more challenging and interesting work for those of us who crave it. In my optimistic moments, I think maybe this trend is a solution for the fundamental problem of the software industry, that the demand for programmers has always by an order of magnitude exceeded the demographic supply of people who can really do it.
- Vivtek 16y ago
  It's not a trend. It's the very nature of computer science. COBOL was a way to program computers directly in something like English, without the need for a programmer to write all that machine code and manage the registers. SQL was a way to program computers directly by describing the data you wanted to retrieve, without the need for a programmer to write the COBOL to hit your VSAM tables. There will always be programming work, because there will always be a need to formalize knowledge and processes - I believe it will eventually be automated, but that is an NLP-equivalent problem. It's not going to be solved with today's technology. Perhaps a better take-away would be that such "non-programming programming" platforms should still be written by people who understand the processes we've developed to ensure more workable software, things like version control and unit testing. It's not like these couldn't be integrated with this sort of easy-to-access domain-specific tool that permits technically less savvy people to codify some of their own knowledge.
  - 16y ago

gruseom 16y ago

I agree with the analysis and have come to the same conclusions over the years. Still, there's one huge exception: the spreadsheet. That's the one UI that has been massively successful at letting non-programmers program without knowing they're doing it.

regularfry 16y ago

It's very, very tempting to believe that this is true. However, the example picked - business process management - is such a spectacularly badly tooled, over-promising and under-delivering area that I don't think it's possible to draw conclusions that wide from it. BPM has the potential to support some really agile business styles, but I just don't see (or hear - maybe I just haven't got my ear close enough to the ground) that it's being applied to the right businesses at the right time. The best time is right at the start, which means that the tools need to be small, simple and agile, not bloated and overweight. Everyone deals in abstraction to some degree; business owners and managers are no different. We just need to find a way to map their abstractions to ours in a way that's easier for them to understand. I don't know what that would look like, but I also don't expect it to be a dumbing-down. I do know that BPEL and BPMN aren't it.

motters 16y ago

I expect that in future there will be more automated programming, based upon a vague description of the problem. However, I've seen very little progress made in this domain other than a few applications of genetic programming and the use of Wizards or UML templates. In the early days of my software career I encountered plenty of situations which had resulted from the use of Wizards to generate database applications by non programmers. The results were always quite disastrous.

utoku 16y ago

I think one of the big mistakes is the assumption that one can get away from symbols and language by using gadgets, windows, or flowcharts. Even if you succeed at some level, you end up with a different language, which still requires programming and abstraction skills, but the language usually ends up being inefficient. I find that written symbols are very efficient. At least, as long as I have this keyboard in front of me.

InclinedPlane 16y ago

No matter how easy you make programming there will always be an irreducible complexity in creating a tool for a task. What form that task takes and the difficulty involved may change but ultimately there is a kernel of "programmingness" that you won't be able to get rid of. More so, making easy projects trivial and making hard tasks easy merely makes previously impossible tasks possible, so there will always be developers pushing the envelope programming at the maximum level of difficulty that humans are capable of. No different than any other skill in history.