Access coding advice needed

[Sandy H]

Hi
I was wondering if I can get some other Access developer's opinions on the
following.
I am currently working on an intermediate project where I have been given
most of the responsibility for coding. My project manager has a background
in C++ and VB programming and he has very different ideas to me about how
things should be done. He will draft up an outline of a function and then
ask me to code it. When I have finished coding, I pass it back to him where
he pretty much rewrites it using his own style (lots of classes, dynamic
arrays and coding that I find extremely complicated to read and understand).
To make matters worse, he doesn't always get his new code working and
expects me to get his code working which is quite difficult when I don't
really understand his code or way of thinking.

This is the first time I have encountered a developer in Access that I have
been unable to quickly understand and am thinking about terminating the
contract because I feel that our styles are just way too different. I am
keen to learn from others but believe that the project will suffer due to
our different styles.

What do others think? Should I be making every effort to learn and adapt to
his style or is it fair to say that some coders are just too different to
work alongside?

Thanks in advance
Sam

 

[Stefan Hoffmann]

hi Sandy,

What do others think? Should I be making every effort to learn and adapt to
his style or is it fair to say that some coders are just too different to
work alongside?

http://www.canonical.org/~kragen/tao-of-programming.html

You should define test cases (unit tests) to delegate responsibility.

mfG
--> stefan <--

 

[Larry Linson]

I certainly would not presume to advise you on the course of action you
should take. If it were me, I'd first have a calm, peaceful chat with the
person, raising my concerns as to the effect on the project of the
situation, and then decide whether additional action would be appropriate.

There used to be a common little cardboard sign often pinned to cubicle
walls: "Keep It Simple; I Baffle Easy." It is unfortunate that, all too
often, applying "enterprise" techniques (as you describe) to simple problems
makes them "baffling". Or applying "guts-level" techniques from the world
of C / C++ to something as naturally simple as VBA can make them "baffling".

I would have to be hard up for the work, or compensated very handsomely, to
subject myself to someone who took my perfectly-good, working code and
changed it to suit his personal view, in the process making it not work, so
that I had more work to do. I only work on time-and-materials basis, anyway,
but this situation sounds as if some rate escalation would be in order.

My view would differ, however, if the code was being changed to comply with
documented development standards of the organization paying the bills, I had
been aware of those standards, and had agreed to follow them as a condition
of being contracted. From your description, it sounds possible that your PM
has some _undocumented_ development standards; in which case, perhaps you
should request that he either document them, or teach them to you, so as to
avoid the irritation that is happening now.

There are developers in every category. I once had occasion to be on a
project with a programmer who'd implemented a major application, tens of
thousands of lines of PL/1 code, single-handedly (possibly because nobody
could work with him). He bragged that it was all "structured programming".
I never had occasion to read any of his code, but just from being around
him, would have bet that it never violated any rules of structure, but that
it would be near-to-totally incomprehensible to anyone except the fellow who
wrote it.

Larry Linson
Microsoft Access MVP