Challenges using service programs, binding directories, etc.

(A followup to my thread "External procedure call returns a value. Does it
need to be a service program?")

So, I had a bit more discussion with my supervisor about the utility I
packaged up in a service program, and the major qualms appear to be related
with maintaining either a) the service program, and/or b) the programs that
use them.

Apparently, there was a highly regarded, talented developer who is no
longer with the company and who packaged a bunch of procedures in a service
program. The service program is used fairly extensively here, but anytime
anyone needs to modify something in the service program, or modify
something in the programs that use the service program, there is a
"gnashing of teeth" because of a history of gotchas that prolonged what
should have been a simple modification/compile into "WTH isn't this
working?" trial of chasing down things related to the service program. My
supervisor did not give details on what the issues were, as they rarely
need to touch the affected applications anymore, so I don't know what the
exact issues were. But, obviously, the battle scars are still kinda raw.

I may be asked to present my case to the "group of 3" development leaders
here, and it would be nice if I can present how to overcome the typical
challenges. If anyone is aware of articles that discuss this and, as well,
the benefits to using service programs, I would appreciate links.

Other factors:
1) To my knowledge, no one here is an "expert" on service programs, binding
directories, etc.

2) We use Turnover here, and, so, there is a specific way to set up a
service program and related objects, but I haven't been able to find any
documentation that shows the details on this. I have the user guide, but
searching for guidance on their TCRTSRVPGM command was fruitless (no help
on the command itself), and I'll need to understand parameters like EXPORT:
Create command for RPGSRV type code: SOFTTURNE/TCRTSRVPGM
SRVPGM("&LI"/"&OB") EXPORT(*SRCFILE) SRCFILE(*LIBL/QSRVSRC) ACTGRP(*CALLER)
OPTION(*DUPPROC *DUPVAR) USRPRF(*OWNER)

3) We are very tight on developer resources, and have been for a long
time. There's nothing to indicate that the "group of 3" is reluctant to
move forward on doing things better, but at the end of the day, there's
work to be done, and a huge backlog waiting for them. I think if I were
able to provide a documented, proven process to handle service programs, it
might go a long way in gaining wider acceptance.

- Dan