Re: AS Library Question
Re: AS Library Question
- Subject: Re: AS Library Question
- From: has <email@hidden>
- Date: Sat, 19 Dec 2015 17:46:43 +0000
On 18/12/2015 16:55, Stan Cleveland wrote:
As the OP on this thread, I never imagined that it would run so
long—or so deeply into the workings of AS. The generous contributions
by all—but especially has, Shane and the other, other AppleScript
Chris—have provided extremely helpful insights into several areas of
AS. I, for one, am in awe of the knowledge and experience brought by
the contributors to this list. Thanks to you all! Stan C.
Honestly, I despise such discussions, because they are a huge red flag
declaring that the product has failed to do its job. In this case, that
job is enabling a wide range of people whose expertise is in a wide
range of skilled specialist domains not including software develoment to
create their own scripts that do what _they_ need to do quickly and
easily, without having to sleep through several years of CS school to be
able to do so first. Such discussions do not make users cleverer or
wiser or better at _their_ jobs; they just clog their brains with
pedantic irrelevant guff that, if the programmers had done their job
right in the first place, would *not exist at all*.
Therefore, the correct reaction to all such discussions is "fix the damn
product already". Eliminate the problem at source, and the need to
discuss its details or consequences magically disappears completely,
allowing *everyone* to get on with more useful productive thing instead.
My problem with not just the AS team but a lot of programmers and
programming teams is that they simply don't *talk to their users*, which
means they don't know their users: they don't know how their own users
think, what they do, or why they do it. I mean, how can anyone present
himself as an expert problem solver here to make his users happy and
efficient when not only does he have zero knowledge or interest in the
problem, but half the time doesn't even realize (and/or admit) the
problem exists?! Frankly, the best thing clients can do in such
situations is thank the developer kindly for his time and throw him out
the door, cos the longer he sticks around the more likely he is not only
_not_ to solve their existing problems, but also to invent new problems
for them as well.
BTW, I observed this developer-user dynamic [sic] first-hand when I
turned pro, and _still_ shake my head thinking about it, because nothing
in this world is dumber than very smart people. And computer programmers
are very smart indeed.
Me, I always talked to my users and was never afraid to ask them
questions - even really basic and dumb-sounding questions - to help me
understand what their jobs entailed. Because understanding that work,
and how they do it, and why they do it one particular way and not, say,
another, gave me a far better chance of building a solution that
actually fit their needs.
For me, being a bear of very little brain, doing what I needed to do to
understand the problem I was supposed to solve was (hah!) a total
no-brainer. I just don't have the brainpower to build large complicated
software systems that repeatedly fail to meet the user's needs, but by
learning the problem space first I can shortcut 90% of that make-work
and get away with writing the smallest, simplest, dumbest code that does
the job. Which, funny enough, is usually all the user actually needs in
order to do their job - and it's _their_ job, not our code, that _they_
(rightly) care about[1]. Software's just something to go wrong and get
in their way; doubly so when it doesn't work right.
Likewise, once users realized I wanted to listen and understand and
wasn't just an arrogant know-it-all only interested in telling them_ -
the experts - how to do _their_ jobs, they were delighted to let fly
with information, insights, and ideas. A lot of the best tools I gave
them sprung from such interactions, and we got on like a house on fire.
As I've said before, even people who think I'm a total dick adore my
work, not cos of who wrote it but because it works right and enables
_them_ to do their own awesome stuff.
Conversely, I noticed over several years that I never saw a developer
from the "Real Programming" team ever step from their glass office onto
the shop floor and just talk; in fact, I'm not sure I _ever_ saw
developers mix much with the people that were using their work. Any
communication there was was chaperoned through layers of management,
thus resembling a very slow game of Chinese whispers. Often as not,
their software was late, horrid to use, often crippled and buggy as
anthills, and made users frustrated and miserable because something
supposed to make them _more_ productive was making them _less_
productive instead.
Sure, lack of two-way trust and communication between developers and
users isn't the only problem that produces poor products and worse
relationships (dysfunctional managers, delusional salesmen, crippling
technical debt, and a whole host of other corporate SOP are also
common), but it's probably the quickest and cheapest way to improvement.
This is why I'm such an absolute believer in end-user programming,
because if programmers insist on not talking to us users then maybe it's
time us users cut them out entirely.:)
But then, if programmers simply gave us what we actually needed when we
actually needed it, I'd never have been driven to teach myself
AppleScript (and then Python, C, and so on) so I could finally do the
damn job right myself. I leave it to everyone else to decide whether
they think it was worth it...;)
Regards,
has
--
[1]
http://www.soloseo.com/blog/wp-content/uploads/2007/11/what-the-customer-actually-wanted.jpg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden