[ale] Different kinds of developers [was: Re: Programming language groups in ATL]

[Daniel Kahn Gillmor]

On Tue 2008-06-24 09:40:25 -0400, Chris Fowler wrote:

> There is a lot of text on the Internet on the difference between a
> Windows programmer and a UNIX programmer.  I have one generalization
> that I think fits the most.
>
> The UNIX programmer will write a program to work on the CLI first.
> Then that programmer will develop a GUI that executes the CLI
> program.  We see this often in Linux.
>
> The Windows programmer will design the GUI first.  There will be
> forms and buttons with no code behind them.  After the design is
> mostly done that same programmer will start writing the real code
> that does real work.

Another way to see this difference for a program addressing a given
problem domain is whether the developer is more interested in
providing:

 0) programmatically-accessible conceptual primitives associated with
    the problem domain, or

 1) an intuitive interface for humans to do the most common tasks
    related to the problem domain.

This is not necessarily a UNIX/Windows divide, but unfortunately it
often breaks down that way.  

The sad part for humans who use computers (and they're the point of
these machines, are they not?) is that for a healthy computing
infrastructure, we need both things fleshed out, and they are *very*
different tasks.

Without developers providing good, flexible, powerful primitives
(that's type 0), there will be no basis on which to advance new
operations that may very well become "common tasks" for users in the
future.  This leads to stagnation and concept lock-in.

But without developers providing good, intuitive interfaces for common
tasks (that's type 1), most users will never get to experience working
in the problem domain.  Proper use of conceptual primitives requires
significant mental investment in understanding the entire problem
domain, which few people are likely to muster.  There are just too
many problem domains out there for folks to really understand the
nuances of all of them.  

And GUIs built directly from the CLI (instead of from the expected
user's point of view) are often hideous monstrosities [0], unusable by
all but the folks who already understood the conceptual primitives in
the first place.

Without a critical mass of users, even the underlying conceptual
primitives will never get the level of testing, engagement, and
feedback necessary for a healthy toolset.  This constant engagement is
doubly necessary now that all computing is essentially networked,
since the subtly-shifting network seems to cause bitrot in abandoned
programs.

Most folks on this list probably agree that it's a bad deal for the
users of Microsoft that MS doesn't provide (or encourage their sphere
of programmers to provide) programmable conceptual primitives, a
functional command line, etc.  We can see the stagnation, bugginess,
and lock-in that comes from that decision.

But the UNIX and free software world needs to step up and acknowledge
and encourage the work of strong user interface designers.  It is to
our shame (and our platform's detriment -- not to mention our users')
that we only have a few good examples of human-centered design.

So please don't say that starting from the human-facing UI (even with
"no code") is not "real work".  It may not even involve a computer
(i've seen good UI developers work entirely on paper and whiteboard),
but it is real work.  It's complicated and difficult, possibly even
moreso than conceptual primitive work, because humans are complicated
and difficult subsystems to interact with.  And a good human-centered
UI will often encourage a re-assessment of the conceptual primitives
themselves, because there may be features or optimizations within the
problem domain that only become relevant when you're placing your work
directly in front of a bipedal primate.

FWIW, i'm a dyed-in-the-wool type 0 programmer, who struggles mightily
not to let down my users because of my personal predilections.  I fail
most of the time.

Regards,

        --dkg


[0] a GUI designed after the CLI: this is just the first that came to
    mind, and i don't mean to pick on xcdroast especially:

      http://www.xcdroast.org/xcdr098/sshot7.html
  
    if you understand this interface (even without the "advanced write
    parameters"), you already know way more about writable optical
    media than probably 99.9% of humanity.  And even if you know what
    "fixate" means in this context, what happens if i make sure "do
    not fixate after write" is checked, and then click the "Fixate
    CD-R/RW only" button?  This is not a UI geared for wide-scale
    adoption or general usability.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
Url : http://mail.ale.org/pipermail/ale/attachments/20080624/38547909/attachment.bin