Is This Development?

[strvariant]

I'd like to get some feedback on what I call 'Analysis Bleed'. In past jobs
I have noticed a trend that starts to develop after about 6 months. Once an
employer sees that the apps I develop are doing what they wanted I always
get asked to provide reports. Okay --- that's a primary function that the
app provides, I'll write the reports like you want. But this seems to
always lead to the employer requesting more and more reports and putting
more and more development projects on the back burner. And after a few
months of adding multiple reports I am then tasked with running these
reports instead of moving on to the new projects. Once I am running these
reports and updating the app on a daily basis, instead of the user using
the app like it was designed I become what the user should be --- the user.

Is it just me or does anyone else hate running reports? I normally start
looking for new contracts/jobs when I see this happening. Is this a normal
trend that I should just accept as part of being an Access programmer or is
this just a way for the employer to get use of my skills instead of relying
on the business analysts that they employ?

Just asking --- Thanks. strvariant

[Randy Harris]

"strvariant" <no.email.com> wrote in message
news:Xn***********************@216.196.97.136...

I'd like to get some feedback on what I call 'Analysis Bleed'. In past jobs I have noticed a trend that starts to develop after about 6 months. Once an employer sees that the apps I develop are doing what they wanted I always
get asked to provide reports. Okay --- that's a primary function that the
app provides, I'll write the reports like you want. But this seems to
always lead to the employer requesting more and more reports and putting
more and more development projects on the back burner. And after a few
months of adding multiple reports I am then tasked with running these
reports instead of moving on to the new projects. Once I am running these
reports and updating the app on a daily basis, instead of the user using
the app like it was designed I become what the user should be --- the user.
Is it just me or does anyone else hate running reports? I normally start
looking for new contracts/jobs when I see this happening. Is this a normal
trend that I should just accept as part of being an Access programmer or is this just a way for the employer to get use of my skills instead of relying on the business analysts that they employ?

Just asking --- Thanks. strvariant

You comments include nothing about fees. When contracting a project, do you
specify a set number of reports to be included? Do you also make it clear
that there are additional charges for additional reports?

I cannot envision an environment where the client asks you to run reports.
I have set up systems to automatically run reports and post results for
download or on web pages. Aside from that, reports should be run by users.

My 2 cents worth,
Randy

[Larry Linson]

"Employer" or "client"?

If it's an employer, they may well regard you as a "jack/jill of all trades"
when it comes to work assignments. Back in my days as an "employee", I did a
lot of different tasks at different times.

Since I've been on my own, I've never, ever had a client who was willing to
pay my rates for me to run reports. If yours does, then they have deeper
pockets or your rates are too low. <GRIN>

Larry Linson
Microsoft Access MVP

"strvariant" <no.email.com> wrote in message
news:Xn***********************@216.196.97.136...

I'd like to get some feedback on what I call 'Analysis Bleed'. In past jobs I have noticed a trend that starts to develop after about 6 months. Once an employer sees that the apps I develop are doing what they wanted I always
get asked to provide reports. Okay --- that's a primary function that the
app provides, I'll write the reports like you want. But this seems to
always lead to the employer requesting more and more reports and putting
more and more development projects on the back burner. And after a few
months of adding multiple reports I am then tasked with running these
reports instead of moving on to the new projects. Once I am running these
reports and updating the app on a daily basis, instead of the user using
the app like it was designed I become what the user should be --- the user.
Is it just me or does anyone else hate running reports? I normally start
looking for new contracts/jobs when I see this happening. Is this a normal
trend that I should just accept as part of being an Access programmer or is this just a way for the employer to get use of my skills instead of relying on the business analysts that they employ?

Just asking --- Thanks. strvariant

[Keith]

"strvariant" <no.email.com> wrote in message
news:Xn***********************@216.196.97.136...

Is it just me or does anyone else hate running reports? I normally start
looking for new contracts/jobs when I see this happening. Is this a normal
trend that I should just accept as part of being an Access programmer or
is
this just a way for the employer to get use of my skills instead of
relying
on the business analysts that they employ?

Are you a contractor? In my "day job" I'm a salaried employee and always
make it very easy for the end user to run reports (I hate running them too,
it's boring). When I get freelance work I'm only ever tasked to do
development work. I'm guessing that clients don't want an over-paid report
runner! If you're a contractor on a handsome retainer then I wouldn't worry
so long as you can pay the bills :o)

Regards,
Keith.
www.keithwilby.com

[David W. Fenton]

"Keith" <ke*********@baeAWAYWITHITsystems.com> wrote in
news:42**********@glkas0286.greenlnk.net:

"strvariant" <no.email.com> wrote in message
news:Xn***********************@216.196.97.136...

Is it just me or does anyone else hate running reports? I
normally start looking for new contracts/jobs when I see this
happening. Is this a normal trend that I should just accept as
part of being an Access programmer or is
this just a way for the employer to get use of my skills instead
of relying
on the business analysts that they employ?

Are you a contractor? In my "day job" I'm a salaried employee and
always make it very easy for the end user to run reports (I hate
running them too, it's boring). When I get freelance work I'm
only ever tasked to do development work. I'm guessing that
clients don't want an over-paid report runner! If you're a
contractor on a handsome retainer then I wouldn't worry so long as
you can pay the bills :o)

Another issue is making reports dynamic.

Most users with a little Access report writing experience seem to
think that a report that shows all invoices and a report that shows
just the open invoices is a completely different report.

Because of that, I make sure that any report that has foreseeable
filtering requirements is designed from the ground up with filtering
built in.

One project I took over in 2000 had something like 60 or 70 reports.
I reduced that to 6 or 7 reports, because it was really just 6 or 7
identical reports tied to different data sets. This cost them a lot
in development time, but in long-term maintenance it was a huge win,
as, since that time, they would have added another 20*7 reports if
they'd continued doing it the old way, when all they do now is add a
record to a data table in order to get the new set of reports.

In my experience, most clients don't need nearly as many ad hoc
reports as they think they do -- they just need certain variations
on a finite number of basic reports, most of which are fairly easily
foreseen if you understand the data and their business.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[strvariant]

"David W. Fenton" <dX********@bway.net.invalid> wrote in
news:Xn**********************************@24.168.1 28.74:

I can do some pretty sophisticated things with VBA but the custom
report/filter idea has always been one of those areas that I have neglected
to focus on. Mainly because of how near and dear I hold reports. You're
right about the hundreds of 'duplicate' reports that multiply on top of
each other. I'd be interested in setting up a 'report command center' so to
speak. That would help make reports much more interesting for me. Any sites
that might have some examples on such a thing? Beyond the normal 'Date
Range' textboxes that generally get put on the reports already?

Thanks again for the input everyone.

strvariant

[David W. Fenton]

strvariant <no.email.com> wrote in
news:Xn***********************@216.196.97.136:

I can do some pretty sophisticated things with VBA but the custom
report/filter idea has always been one of those areas that I have
neglected to focus on. Mainly because of how near and dear I hold
reports. You're right about the hundreds of 'duplicate' reports
that multiply on top of each other. I'd be interested in setting
up a 'report command center' so to speak. That would help make
reports much more interesting for me. Any sites that might have
some examples on such a thing? Beyond the normal 'Date Range'
textboxes that generally get put on the reports already?

I use what I call a "report switchboard" in my apps. An example can
be seen here:

http://www.bway.net/~dfassoc/Park/Reports.html

It's basically driven off a table populated with the names of the
reports along with friendly descriptions and fields that define
certain characteristics, such as how to open the report (directly
via DoCmd.OpenReport, by calling code, or by opening a dialog form).

Another example that's more complex, since it has a high-level
choice that is made before most reports are printed is here:

http://www.dfenton.com/DFA/examples/...witchboard.gif

In both cases, when a filtered report is called directly, it means
that there's a dialog form called called in the report's OnOpen
event that pulls the criteria from the dialog form and changes the
recordsource of the report to reflect the filter criteria.

In other cases, I use a class module as a data storage structure.
This is particularly helpful for printing groups of reports that
need to use the same criteria, but you don't want to annoy the user
with multiple dialogs. The second example above uses a class module
to store the campaign choice and all the choices made from dialogs.
The OnOpen events of the reports refer then to the class module
instead of opening the dialog form. In a few cases, I set up the
OnOpen event so that if the class module has not been initialized,
then it opens the dialog form directly, but otherwise skips the
dialog.

I've been intending for quite some time to put together a sample
database, and even started in on it a little over a year ago, but
never got around to finishing it up.

It's too bad the question didn't come up last week, when I had time
-- I would have gone ahead and finished it up, but this week is way
too busy!

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc