How to compromise with other programer/PM's bug?

B

Boki

Hi All,
Our PM( project manager) want to do a perfact job, and then he
always change new spec; and then we have to change code again and agin.
Moreover, anyone's change is possible to affect our's design, right? and
then we have to update again and again..

How do you think?

Best regards,
Boki.
 
R

Roedy Green

Our PM( project manager) want to do a perfact job, and then he
always change new spec; and then we have to change code again and agin.
Moreover, anyone's change is possible to affect our's design, right? and
then we have to update again and again..

Though it may be frustrating, you write the contract so that you get a
lot more money when this happens. If you are an employee, the person
who oks the changes is the one who gets called on the carpet for going
over budget.

Usually you have the other problem, a boss trying hide garbage under
the rug who won't let you take time to refactor/redesign code.
 
R

Roedy Green

Our PM( project manager) want to do a perfact job, and then he
always change new spec; and then we have to change code again and agin.
Moreover, anyone's change is possible to affect our's design, right? and
then we have to update again and again..

If changes to only vaguely related code trigger changes in yours, then
you need to thing harder about how to decouple, so that only one small
part of your code ties into the other code, and all your code goes
through that interface.

One of things I got such a kick out of in your situation is PREDICTING
what the boss was going to demand to be corrected and planning ahead
so that I could kick in the new implementation by changing a table or
a configuration constant. I would come back 15 minutes later to the
astounded boss with the completed work.

The art of writing maintainable code is trying to guess what will
likely change and plan ahead to make those changes easy. I have
written an essay on how to make it difficult. See
http://mindprod.com/gloss/unmain.html
 
R

Rhino

Boki said:
Hi All,
Our PM( project manager) want to do a perfact job, and then he
always change new spec; and then we have to change code again and agin.
Moreover, anyone's change is possible to affect our's design, right? and
then we have to update again and again..

How do you think?
I think you'd better get used to this. After 20+ years in systems work, let
me suggest that this sort of behaviour is more the rule than an exception.
Users and managers tend to change specs at frequent intervals, even when
they should know that it causes all sorts of negative consequences, like
frustration on the part of the developers.

I was once on a project that involved 150 full time people, $15 million
dollars, 2.5 years of elapsed time and the prestige of some high profile
people. One of the first things the project leaders agreed upon was that the
specs couldn't change after a certain date. At all. Despite that
realization, major changes were being made almost every day, even well after
that date had passed. I'd like to be able to tell you that the project
succeeded despite this violation of their own principles but I'd be lying.

It's not pretty but it does tend to be the way the real world works. It
might be best to accustom yourself to this now, rather than letting it grind
you down later.

Rhino
 
R

Rhino

Boki said:
Hi All,
Our PM( project manager) want to do a perfact job, and then he
always change new spec; and then we have to change code again and agin.
Moreover, anyone's change is possible to affect our's design, right? and
then we have to update again and again..

How do you think?
I think you'd better get used to this. After 20+ years in systems work, let
me suggest that this sort of behaviour is more the rule than an exception.
Users and managers tend to change specs at frequent intervals, even when
they should know that it causes all sorts of negative consequences, like
frustration on the part of the developers.

I was once on a project that involved 150 full time people, $15 million
dollars, 2.5 years of elapsed time and the prestige of some high profile
people. One of the first things the project leaders agreed upon was that the
specs couldn't change after a certain date. At all. Despite that
realization, major changes were being made almost every day, even well after
that date had passed. I'd like to be able to tell you that the project
succeeded despite this violation of their own principles but I'd be lying.

It's not pretty but it does tend to be the way the real world works. It
might be best to accustom yourself to this now, rather than letting it grind
you down later.

Rhino
 
B

bokiteam

I can only say this is not profession PM.

At least, I don't agree this. : )


Best regards,
Boki.
 
R

Roedy Green

I can only say this is not profession PM.

At least, I don't agree this. : )

Your disillusionment is similar to a similar one coming when you
discover that government works nothing at all the way you learned in
civics class.
 
I

Ian Pilcher

I can only say this is not profession PM.

As others have pointed out, you should be very grateful to have a P.M.
who gives you the time to change your code when the spec changes, and
presumably creates additional revenue for your employer by doing so.

This is, in fact, the very definition of professional project
management.
At least, I don't agree this. : )

You need to grow up or change careers.
 
L

Luc The Perverse

Roedy Green said:
Your disillusionment is similar to a similar one coming when you
discover that government works nothing at all the way you learned in
civics class.

I can think of plenty of US examples. Do you have any from Canada?
 
R

Roedy Green

I can think of plenty of US examples. Do you have any from Canada?
We are wandering off topic here.

Things not covered:

1. the way parties change their platforms for strategic reasons in a
multiparty election.

2. the amount of lying at election time about what a party intends to
do and what they do.

3. that elected governments reflect the will of the people, rather
than the will of the powerful.

4. how bribery works. It is rarely handing over an envelope of cash.
 
M

Monique Y. Mudama

3. that elected governments reflect the will of the people, rather
than the will of the powerful.

Er, did you mean that the other way around? In theory it's the will of
the people ... in practice it's whatever the powerful can spin enough
people into swallowing ...
 
R

Roedy Green

Er, did you mean that the other way around? In theory it's the will of
the people ... in practice it's whatever the powerful can spin enough
people into swallowing ...

yes. I was not consistent it describing the they were taught or the
way they are.
 
B

bokiteam

NO, this PM never give me extra bonus, what I ever get is - US$25
dinner(s) .. = = ...

That's a very important reason I don't like to work hard for him.

I work hard about 9 months before, almost no holiday/weekend, what I
get ? few times of free US$25 dinner

( This PM is different to our president, my president will give us
extra bonus when he is requiring extra work)


I remember CMMI said:

PM MUST design their SPEC very carefully, because it can't be changed
when engineers ( around the world ) start working!

Now, what I can do is accept his requirement ( this PM is my boss's
boss )
But I will really prepare better ability myself, and find a better
enviroment when this contract was expired.

Thank you very much.

Best regards,
Boki.
 
T

Tim Ward

Roedy Green said:
2. the amount of lying at election time about what a party intends to
do and what they do.

Some of us do try quite hard not to, actually.

If someone puts an untrue statement on one of my election leaflets and I
don't catch it before it's printed then it *will* get spotted by the punters
and I *will* lose votes and I *will* lose my seat if it's bad enough or
frequent enough. The power of the internet - an error on an election leaflet
is usually being discussed on the local newsgroup long before we've finished
delivering it.

On one occasion I insisted that an entire print run of leaflets be scrapped
rather than delivered, and on another I required a correction to a mistake
to be printed in the next leaflet. My opponents, on the other hand, don't
always appear to be quite so careful. Possibly that's why I get elected and
they don't :).
 
?

.

NO, this PM never give me extra bonus, what I ever get is - US$25
dinner(s) .. = = ...

That's a very important reason I don't like to work hard for him.

I work hard about 9 months before, almost no holiday/weekend, what I
get ? few times of free US$25 dinner

Welcome to the real world. I would imagine everyone has or will work for
someone like this. A PM is always being squeezed from both sides. The
people above him don't want to give him more time/resources or less scope.
The people under him want more time/resources or less scope. A good PM
will find the right balance.

Last company I worked at hired a PM who honestly believed that whatever
estimate development gave him for time he should cut in half. If we told
him it would take 6 months he'd set the schedule for 3 months. The reality
was that development would take 6 months, plus testing, plus
documentation, plus installation, etc.

At least your PM buys you dinner occasionally. I was told if I'm not
working ATLEAST 60 hour weeks (for 37.5 hours pay) then I'm not working
hard and if I'm not working hard I'm on a list of people who might get
laid off. I quit and work for someone much more reasonable now.

If they don't appreciate you, find someone who does. Just be careful that
you are not jumping out the frying pan and into the fire.
( This PM is different to our president, my president will give us
extra bonus when he is requiring extra work)


I remember CMMI said:

PM MUST design their SPEC very carefully, because it can't be changed
when engineers ( around the world ) start working!

I find it hard to believe anything that talks in absolutes. If CMMI
indicates "MUST" and "CAN'T" then it will not work. There must be some
level of flexibility in whatever you do.

If the customer is willing to pay for it then specifications can change.
The difference between a good PM and a bad PM, in my humble opinion, is a
good PM will have someone above them pay for the change. A bad PM will
have someone under them pay for the change.
 
B

Boki

"Hello World!" Here is a smile for every body ":D"

[A PM is always being squeezed from both sides. The people above him don't
want to give him more time/resources or less scope. The people under him
want more time/resources or less scope. A good PM will find the right
balance. ]

[The difference between a good PM and a bad PM, in my humble opinion, is a
good PM will have someone above them pay for the change. A bad PM will have
someone under them pay for the change. ]

Good comments.


[I quit and work for someone much more reasonable now.]

Good choice.

[ Just be careful that you are not jumping out the frying pan and into the
fire.]

Thanks. : )


I only want to explain, the CMMI didn't use that kind of word(s), that is my
personal description after study.


btw, I believe I can analysis our PM is good or bad now ... :D

Best regards,
Boki.
 
D

derek

Check out this book :

'The Career Programmer : Guerilla Tactics for an Imperfect World'
by Christopher Duncan
 
B

bokiteam

Thank you very much, this will be one of my studying this week. : )

Best regards,
Boki.
 
B

bokiteam

In fact, that's one of my plan :)

Any suggestion? :) ( not limit to coding/programmer )

Best regards,
Boki.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top