[AccessD] Burn-out

Art,

I disagree only with the "in any app" part and I don't feel I am even
splitting hairs.

Unless your definition of a novice is someone more advanced than I have in
mind.

While I might give an app to a novice to do for me I, i dont like to share
work until mostly in production. MS Access apps require constant awareness
of most of what the database is doing and I have learned painful lessons
about handing off my database to someone else to split load. Almost always
I find they can't do much without fiddling with what I have done or am
working on and vice versa... no matter how close or far apart we are in
skill level. Therefore in any serious MS Access database with moving parts
and VBA... there is no way I will again give a project I am doing to
another novice developer to share.

The only exception might be table setup. But even then i have to inspect
and test and there are handoff and schedule issues... not worth it, i find
i may as well dive in myself when i am ready to focus on it.

Where I have made an exception is letting another developer chew on my
database so he could learn. But that was investment for each of us, not
dividing up the work per se. That person may be reading this ;) so let me
be clear I am not disparaging him or his work! Just pointing. Out it was
frustrating for both of us and if not for the non-production (ie,
professional development ) side benefits,  I am sure no novice nor I would
consider it a winning development strategy.

Otherwise I agree with all you said.
 On Jan 30, 2012 2:38 PM, "Arthur Fuller" <fuller.artful at gmail.com> wrote:

> I'm entirely with you on the points you made, Gustav. Frankly, I am pretty
> expert at saying NO and LATER, but it took me years and numerous battle
> scars to arrive at that wisdom. Now I go even further: I read the specs, do
> my best guess at hours required, then double the hours, because I have
> learned to defend against my optimism, and because I know that there will
> be feature-creep, regardless of the precision of the specs.
>
> On the team concept, I also agree, for several reasons:
>
> 1. In any app, there are parts that a novice could perform under guidance.
> 2. In any app, there are parts that demand a little rocket-science, and
> those are best left to the most seasoned member of the team.
> 3. In most situations, design of the UI is fundamentally different than
> implementing the code required -- different skill sets, and ideally,
> different people.
> 4. The strength of a chain is defined by its weakest link -- a superb
> reason to hire an accountant rather than do it yourself.
>
> On Mon, Jan 30, 2012 at 11:08 AM, Gustav Brock <Gustav at cactus.dk> wrote:
>
> > Hi Mark
> >
> > Ha! I missed that completely.
> > This makes the situation clear and simple: You are the only one to blame,
> > and the only one in power to make a change.
> >
> > You just have to learn the words NO and LATER. And supplement with
> > different charges, where you favour those of your clients that are able
> to
> > plan in a decent way.
> > Those over-the-weekend clients always calling in Friday at Noon (because
> > they "suddenly" remember, and have to call you before they turn off for a
> > wonderful weekend!) are used to, that they can get away with this and
> Mark
> > never says no.
> >
> > Also, couldn't you team up with someone? I know, I know ... you are the
> > best, but probably not for everything. And that is needed if someone
> should
> > be able to jump in for you while you are on holiday - with e-mail and
> > remote access shut down.
> >
> > /gustav
> >
> >
> > >>> marksimms at verizon.net 30-01-2012 16:41:32 >>>
> > Sorry no - I'm the management !!!
> > But I've got clients with deadlines and budgets....that THEY SET.
> >
> > I just can't seem to get to a cruising speed of 60 mph.
> > I'm either at zero(doing nothing) or 100 mph(multiple concurrent
> > contracts)....and veering out-of-control.
> > That's my current state.
> >
> > >
> > > Hi Mark
> > > Blame management for poor resource planning. That's the essence of
> this.
> >
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
>
> --
> Arthur
> Cell: 647.710.1314
>
> Prediction is difficult, especially of the future.
>  -- Niels Bohr
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>