Howie Goodell wrote:
> Those normalization-challenged Access programmers may
> never process the human genome, but some human beings somewhere like
> their work and pay them for it. Such programmers are a significant and
> increasing part of the programming world.
I'm not convinced that self-taught Access programmers are any
different to any other kind of programmers. There are also a
great many good expert programmers who don't have qualifications
or a theoretical background.
A GUI interface to code is still code. And whether you build a
loft or a 5-storey building, you're still in construction - the
difference of scalability seems to me to be only to do
with engineering and the scale of the consequences of mistakes.
My understanding of end-user programming (which I would gladly
see a definition of) is that a) they do not see the generated
code and b) any domain knowledge to complete the task is in the
tool and not in the end-user's head. Therefore, knowing the
syntax of language or having a tool that generated code isn't
enough to make a "proper" programmer (that is, someone you would
hire to do a job for you), in the same way that knowing how to
use FrontPage doesn't mean you're necessarily going to build a
good (usable) web site.
Issues to address include comprehension (how to understand
what you've done), usability (will people use if effectively
and painlessly), extendability (can you add to it easily)
and maintainability (can someone else easily add to it if
you're not around). I find it hard to believe that these
are included in end-user tools.
It may be interesting to note that the software industry refers
to coders (or programmers) and software engineers. In a
project team, one person may design and specify and then hand
over to the coder to implement the solution. I suggest that
"end-user programming" is actually end-user coding, and that
the software engineer's skills need to be in the loop
somewhere, either in the end-user's tool or their head.
Paola
