Re: Opinions and experiences with ReportBro

John,

I understand that you're advocating that developers take no responsibility
for reporting once a reporting system is set up for users. I'm aware of use
cases where that works great, including ones where I was the "user" who
took full responsibility and control over reporting. Very often, medium to
large organizations put together "business intelligence" teams, which are
managed by "users", who often select their own tooling, which time and
again cost hundreds of thousands of dollars, in which the IT department may
not have any responsibility whatsoever.

However, full user control does not appear to be what Marco has been
proposing, regardless of what you may be advocating for, or what you think.
That was made clear by the types of tools Marco is using (Freemarker,
xReportDoc) and proposing (ReportBro), plus his delineation of user
responsibilities (report layout plus output conditions). I suggest that you
look at those back-end frameworks and see for yourself that they require
significant Java and Python coding experience.

I won't take time to respond to your elongated position statement because I
don't think you would have written it, except for your fundamental
misunderstanding about what Marco might be proposing.

Nathan.



On Thu, Jul 8, 2021 at 4:26 PM John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Thu, Jul 8, 2021 at 11:40 AM Nathan Andelin <nandelin@xxxxxxxxx> wrote:

In the context of tools and processes that generate reports I really

don't

understand why someone might push for a division of work between "users"
and "developers".

I don't care what the context is, I will *always* push for a division
of work between users and developers.

Maybe we just have different ideas of what a user is and should be,
and what a developer is and should be.

I really don't understand why Marco raised the point by
suggesting a difference in skill levels.

It was several messages ago, so let's revisit exactly what he said.
This is the only place I found where he mentions skill levels:

Marco wrote:

As I see it, I understand that your system is very good if people with a
higher level skill than the end user manage the templates. I'm wrong?

Keep in mind that English is not his first language. But essentially,
all he is saying is that your proposal entails developers being
involved with the templates. I think we are all in agreement there.

I am not sure why you seem to be put off by and fixated on the mention
of "skill levels". Do you object to the implication that developers
have a "higher" skill level than users? I don't think Marco meant to
disparage users in any way. I'm sure skill level here simply refers to
programming ability.

Perhaps Marco will chime in and explain why his shop divides reporting
tools and processes between 2 types of people (i.e. evidently users and
programmers).

I would argue you are the one with two types of people involved, users
and programmers. In Marco's model, once the system is installed, only
users are involved.

Since the number of output
conditions is so small and the amount of work to code one is so trivial,
why would anyone die on a cross defending how that belongs in one court

or

the other?

This is telling. This is precisely the attitude which indicates to me
that we must have very different ideas about what a developer is for,
and how they go about their work.

Without making any value judgments, and forgetting completely about
Marco's scenario, let's say we have a clerical worker and a
programmer. Further, let's say our clerical worker does not have any
programming skills. They were hired to do typing, filing, and
miscellaneous manual tasks.

Now, again without making any value judgments, let's say our clerical
worker happens to type at 60 wpm. And let's say our programmer happens
to be a great typer, at 90 wpm.

How do we best leverage the respective abilities of these workers?
Even though this particular programmer might be 50% more efficient at
typing than the clerical worker, we *still* don't assign clerical
typing tasks to the programmer. We have the programmer spending as
much time as possible on programming-related work.
"Programming-related" could include collaborating with the clerk to
develop software that increases the quantity and/or quality of what
the clerk can accomplish in a given amount of time.

I am going to die on that cross because there is a real opportunity
cost to having the developer spend time on "small" and "trivial"
things. My workplace is actually in that place now. Our tiny
programming staff is busy doing endless small and trivial things. We
have no time to work on big things that can really leverage our
abilities and provide significant *and essentially permanent* value to
the company. Even if we do manage to start on a bigger project, the
constant interruptions to do "ridiculously easy" things is
nevertheless disruptive.

Please understand that I'm not even talking only about tasks that
could realistically be done by either the user or the developer. I'm
saying that even within the sphere of tasks that can ONLY be done by a
developer, if the developer is spending all their time on the
smallest, easiest tasks, but has the programming ability to do bigger,
more impactful things, the organization is not getting as much value
from the developer as they could.

Again, the idea that output conditions like that might be divided between
users or programmers seems contrived to me.

You are the only one doing the dividing. I am advocating for the user
to have full control and responsibility. I do not want the developer
to be involved AT ALL once the system is set up.

John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com