Pete,
< I think this reply has become a little polemical >
> Although there are a wide variety of End-User Programming environments, it
> is not clear to me how design is tackled by the EUP approach.
> 'Traditional' programming makes a distinction between the design stage and
> the development stage, but no such distinction is apparent in EUP, the user
> presumably being expected to design and code the system in a single
> notation. While I can see benefits in this (e.g. shortening the
> develop-compile-execute loop), I can also see problems arising from the
> amount of information and the scale of the task the end-user must deal with
> in a single envronment. This would seem to limit the scale of systems that
> can be developed through EUP and later comprehension of what the system is
> intended to do. Would anyone like to comment?
You mention `traditional' programming and the words `stage' as though design
happens before implementation in a waterfall model approach. Programming and
software engineering are different things. The waterfall model and stages
comes from an outdated view of software engineering. It has never been a real
factor in programming. Programming is very much:
while (not satisfied with the result) {
understand something of the problem
construct a partial solution architecture
design some aspect of the solution to the problem
implement some part of the design
test the implementation
check the continued consistency of the architecture, design and
implementation
plan evolution of the solution
}
In modern approaches to system development, design and implementation
are both different tasks and the same task -- particularly if testing is
included (as it ought to be but is not always). Good system developers
separate design and implementation issues even if they are using the
same notation or more interestingly when they use tools that allow
fluid interworking of design notations, e.g. UML, and implementation
notations, e.g. Java. In fact, used sensibly, Java is both a design
and an implementation notation.
You do not mention analysis or architecture both of which are crucial
to modern systems development. The implication is that end users don't
consider them -- even if they know that such things exist. Her lie the
seeds of doom.
End-user programming is something I am very ambivalent about. On the
one hand systems generated by people not programmers are usually badly
designed, inefficient, error prone, etc. On the other hand programmers
very rarely generate systems that people want without being given very
strong guidance.
Take Access or Paradox and Excel or Quattro Pro. The ability for people
to generate databases without understanding third and fifth normal form
means we have a lot of appalling databases. The ability for people
who do not understand the fact that spreadsheets are probably the most
complicated programming language ever invented and the results are
untestable and error prone to construct spreadsheets has led to some
seriously appalling applications and errors.
So whilst there is a notation problem, there is a more serious knowledge
problem. Tools are being provided to end users that they do not have
the knowledge to deal with. Certainly this could be transformed into
a notation problem, ther fundamental issue is that systems development
professionals do not have the real tools to solve the problem so how
can we expect end users to have this non-existant notation.
Of course such an attitude leaves open the claim of being protectionist
and elitist. Actually I must declare myself guilty on this topic.
As with DIY in the home, I do not care if people do not employ
professional decorators, carpenters etc to do things in their own home
and analogously I do not care if people play at programming for their
own purposes in their own homes. However, I do not want public service
vehicles designed and implemented by amateur DIY people and hence I do
not want infrastructure computing systems developed by amateur systems
developers using inadequate tools.
The problem with EUP is that amateur developers are conned into thinking
they can construct professional level systems that can be used for real
live systems. Of course there are some individuals who could do this,
a psychiatrist friend of mine also happens to be a very good Java
programmer. However, individuals like this are very rare. Most end
user system developers are really inadequately educated and trained in
what they are doing.
EUP clearly has a role in prototyping systems, the domain experts and
real users can construct a prototype to show to the systems development
professionals. The systems development professionals then have an easier
analysis job. They can re-architect the system, design and implement
from this and deliver a far better system that matches the users original
vision. Indeed one role of the systetems development professional is
to show what the end user could do that they did not know they could.
All too often end users are stuck in a design/implementation rut and
therfore produce cruddy systems.
So EUP is really about an horizontal prototype, it is really about
using design of the user interface to get an appreciation of the way the
system must work. This can usually be done without actually building the
real system. So one way forward is to make the very best UI prototyping
tools, EUP is not this at present. This avoids the whole semantic issue.
Of course some aspects of the prototyping need semantics so this is not
a foolproof way forward.
On a political note: The problem with many EUP advocates is that their
hidden agenda is the removal of systems development professionals from
the systems development process for whatever reason.
My overall view: EUP is a positive danger to society except where
it is used as a tool in collaborative ventures between end users and
professional systems developers. I such a situation many of the issues
that you mention are non-issues.
Russel.
PS Many systems development professional need indoctinating with the
above as well. All too many of them are high-handed and arrogant when
it comes to interacting with end users. These people generally need
removing from their posts.
========================================================================
Prof Russel Winder Professor of Computing Science
Head of Department
Department of Computer Science Phone: +44 20 7848 2679
King's College London Fax: +44 20 7848 2851/+44 20 7848 2913
Strand, London WC2R 2LS [EMAIL PROTECTED]
UK http://www.dcs.kcl.ac.uk/staff/russel/
