I don't really have the time for this, but let me jump into the fray with a
few somewhat related but disparate points of my own...

First, with regard to the "bad resources" issue, I've been seeing pattern
for years.  On three separate occasions in my career as a Remedy Developer
contractor, I've been brought in by clients who had a custom
Remedy application which were in varying degrees of being train wrecks.
 The types of problems included extremely poor data architecture, hundreds
of forms and many with no use (and names such as "Test" *in production*),
thousands of workflow objects with no use and no useful naming conventions,
escalations spinning out of control, etc.  In two cases I was able to
"tame" the systems, but in one case it was so bad I outright refused to
even try (I suggested they either find another resource or allow me to
build a new system from scratch..fortunately they chose the latter).

I came to realize that there were two main factors that had enabled these
situations.  First, the fact that the Remedy ARS system makes it so easy to
perform development operations - create forms, create workflow that does
useful things, etc. - that many people who have no business architecting
and developing applications where doing just that.  In candid conversations
with clients, I've describe this situation by saying that "any idiot can
develop in Remedy, and unfortunately many of them do".

This was compound by second factor, which is (was) the confusion Remedy
themselves created in the early days by collapsing the notions of
"administrator" and "developer".  When I was originally taught to use
Remedy, the topics about how to install & configure Remedy were taught
right along side the topics about how to create forms and workflow.  The
documentation largely followed suit.  In fact it's only relatively recently
that the main development tool actually has the word "develop" in its name
and is *not *the (BMC) Remedy *Administrator*.

So these Remedy administrators - people who perhaps had the background to
understand and been taught to perform actual administrative tasks - were
then asked to implement changes to the system because, in everyone's mind,
the notion of "Remedy administration" naturally extended to performing such
changes.  These people then go on to create a few forms and some workflow
successfully.  They created their Customer form and they created their
Inventory form and some workflow around all of this.  And, at first,
everyone's happy because they were able to get this done so quickly.  Time
goes on and they're repeatedly asked to extend the system, and for a while
everyone remains happy.

What happens next (which is what happened in each of those three "train
wreck" systems I've described) is that at some point the system grows
beyond the "developer's" ability to manage.  In my experience it seems to
happen somewhere around a few tens of forms and perhaps a few hundred logic
objects.  In all cases by the time I was brought in the original developers
were gone, but my own forensic analysis of those systems suggested to me
that at this point in the growth of the application the original developer
was no longer able to fully comprehend what was going on.  Before this
point they were able to keep it all in there head and knew where to find
things, but at this point the system just became too large for this
approach, and their lack of skill and coding discipline (e.g. good naming
conventions) meant they had no other recourse.  Problems (bugs) would occur
but the developer was unable to debug the problem.  And instead of
identifying and correcting the root cause (which in many cases were due to
fundamental problems with the data architecture), the developer would add a
"patch" to fix the problem: e.g. the client expected the result to be 100,
so they add a filter to set it to 100 at the end.

So instead of *reducing *the problem set, these developers actually
expanded it.  This pattern would continue for a while until the momentum of
the system eventually ground to a halt, leaving a barely functioning system
on which no one present could implement any changes for fear of making it
worse and the client complaining loudly that none of their changes, even
simple ones, were not being done.  I've only been occasionally or
peripherally involved with the canned apps - what's ITSM now, and what were
the component apps (e.g. Help Desk) a long time ago - but from what I've
seen the pattern there was similar: people with administrator level skills
at best were asked to implement changes, and for the same reasons
eventually reducing the system to being unchangeable and largely unusable.
 And the nearly indelible feeling that everyone - the users and management
understandably, and even some of these so-called "developers" (not so
understandably) - takes away from this experience is that "Remedy sucks".

Does this sound familiar?

It's all really unfortunately because the problem of course has nothing to
do with the core workflow engine itself.  And while I, as a long time
developer of this system, have a long laundry list of complaints about it
from the development perspective (why can't I get my integer table columns
to left justify?!?), it really is an amazing system on which you can build
amazing applications.

And this is a reasonable segue into my next (disparate) point...

It's my own fault that I've only recently resubscribed to ARSLIST and now
have been really trying to join the conversation (I've only infrequently
and briefly joined in the past) , but why does it seem that ITSM is the
only application anyone is interested in?  I ask this question rhetorically
- people are interested in what they are interested in, and of course ITSM
is the big app being pushed by BMC.  But I'm still amazed that seemingly
75% of the postings are directly or peripherally about ITSM, with another
20% (or so) having to do with system configuration and how to integrate
with other third-party systems.  Here we have a system capable of building *any
*database application, and yet ITSM dominates the conversation.  I'm more
interested in core development topics and doing interesting things with
forms, workflow, UI, API programming, etc and seems that only the remaining
5% (or so) of the postings have anything to do with these topics.

It's becoming increasingly clear from all this that custom application
development using Remedy is dying (other posters have mentioned this
recently too).  It does seem to me that BMC is only really interested in
selling ITSM, when you'd think they'd also be doing all they can to broaden
the base of customers using ARS itself.

I do agree with a few other posters that BMC could do a hell of a lot more
to change all this.  For one thing, and as others have mentioned, make the
education on the system more readily available.  What is it now, like
$500/hour for their WBT?  *For web based training?!?  Are you $%^#* kidding
me?!? * As an independent contractor, it's hard for me to foot the cost of
this, much less the instructor led courses.

Another thing they could do is give away developer copies of ARS.  Yes, I
said *give it away*.  When I'm not working for a client (or made other
arrangements), I have no access to a fully functioning ARS server.  During
such off times between clients, I'd *like *to do development work on my own
applications with an eye toward possible future sales, but I can't afford
to purchase and maintain a server license, so I'm effectively shut down.
 It's stupid, because interest in any applications I might create might
convince potential customers to buy ARS.

In an effort to ensure a solid following of their products, companies like
Microsoft and Oracle practically give away development copies of their
software.  Oracle does, outright, give it away: promise that you won't use
it for production purposes and you can download anything you want from
their web site.  And for
$50<http://www.amazon.com/SQL-Server-Developer-Edition-2012/dp/B007RFXQAM/ref=sr_1_1?s=software&ie=UTF8&qid=1394561889&sr=1-1&keywords=sql+server+2012>
you
can buy a developer license to MS SQL Server which is pretty much
functionally equivalent to their enterprise edition.  Both companies
provide tons of online documentation, tutorials, WBT, etc. *for free*.

Why can't BMC adopt such a model?  I have to believe that their bean
counters tell them that it'll be a negative ROI, but that doesn't seem to
be the case with MS & Oracle.

Anyway, enough rambling & back to work.

-charlie



On Tue, Mar 11, 2014 at 8:31 AM, James Smith
<bmcremedyarslis...@gmail.com>wrote:

> I agree. Bad resources lead to the failure of projects.
>
> I got some link which shows pitfalls in service now
>
>
> http://seekingalpha.com/article/1111961-after-interviewing-more-industry-insiders-i-am-even-more-bearish-on-servicenow
>
> Worth reading
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to