
Programmerless programming is just a mirage - edw519
http://www.crazymcphee.net/x/2009/01/17/programmerless-programming-is-just-a-mirage/
======
jdietrich
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.

~~~
danilocampos
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?

~~~
Groxx
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_.

~~~
Tamerlin
That's even worse than the CS student (she had a bachelor's degree in CS, and
was in the final year of her master's degree program in CS)... she actually
attempted to delete an object in C++ by calling its destructor directly.

Needless to say, my company didn't try to keep her when Booz Allen Hamilton
recruited her away from us.

------
gruseom
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.

------
utoku
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.

------
regularfry
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.

------
devmonk
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.

~~~
jerf
I remember people saying that, too.

In 1980.

It really isn't true, and the reasons why it isn't true have been known for a
long time, and it will never be true, and it is this: A (good) programmer is
_always_ prototyping. Virtually by definition, you are doing something that
hasn't been done before. If it had been done before, you would buy it or
download it, it would be a component, and then you would move on to the part
of the problem that _hasn't_ been done before.

It is not true that programming is moving towards a model where you just grab
components off the shelf and wire them together. Or if it was true, it has
_happened_ , it is in the past, it isn't "becoming" true. All the components
mean is that you no longer have to research the best way to handle images, and
you get a lot farther before hitting the unsolved part of your problem... but
it's only the unsolved part of the problem that is interesting. There's no
money in solving solved problems. (Well, that's not entirely true, but this is
a comment reply, not an exhaustive description of all programming niches.) The
unsolved problem is always the focus and pretty much by definition there will
always be more unsolved problems.

If you aren't writing much code and you really, truly are just wiring bits
together, it is time to either learn how to write metacode that wires the bits
together for you and start wiring much, much faster, or to desperately cast
about for a new skillset because you are easily replaceable (or possibly just
_discardable_ ) and you really need to change that as quickly as you can!

~~~
devmonk
Developers are using more and more code that has already been written. Sure we
still code, but if you were coding in 1980 (like I was), then you know what I
mean.

I'm with you and the author that the non-technical customer is not going to be
able to move the legos around on the screen until they have their working
webapp. I've been a part of projects that promised those types of things, and
they were failures for the most part.

But, the trend is to have more and more complicated pieces that the developer
puts together. The developer _feels_ as if he/she has really done something
significant, but what they did technically was more brainless than what a game
programmer wrote in assembly in the early eighties, for sure.

If developers need to know less and less about what is really going on, sure
maybe they will still be called developers, but they'll be closer in function
to the guy making your big mac. It won't happen overnight, but just because it
hasn't happened yet and may not happen during our lifetimes doesn't mean it
won't.

------
motters
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.

------
pessimizer
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
How did they express their models before the BPMN tools?

------
InclinedPlane
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.

