What developers need to always understand is that the PM's
view is the business's view.
The PM's view is the business's view colored by the PM's preconceptions. Good PMs will defer on technical decisions and be firm on business decisions. Bad PMs won't.
If developers have a tough time with developing Windows Forms and would rather use Python daily, they should found a start-up and create a business that is inline with a developer's view.
That's one way to do it. Another good way is to communicate with the PM/business in language that speaks to them (cost/savings, time to build, maintenance costs, etc.) and make the case for Python (or whatever).
Interesting thought:
* Poor developers will pick their technology irrespective of the problem at hand.
* Good developers will pick the most appropriate tool given the problem at hand.
* Great developers look at the problem at hand and write whatever tools from the ground up they need in their chosen technology to make it happen. (See: 37signals with Ruby, developed Rails. Django with The World Company, etc.)
Good PMs will defer on technical decisions and be firm on business decisions. Bad PMs won't.
The logical precursors of this is that technically minded people are either not capable of analyzing business decisions, or that they shouldn't be allowed to anyway because they are technical people. Perhaps both.
If they were capable, there would be no reason for a PM to be firm on a business decision, because the technical staff wouldn't run nearly as high a risk of pushing him to do something stupid.
If we assume they are capable, then this becomes an argument to authority. I would then like to ask the following question: if the people who watch the bottom-line see an improvement based upon a particular decision, do you really think they'll care who made the decision, and what influenced them?
i don't really agree with your assertion about great devs. i would word it such that great devs will write their own tools from the ground up only if there aren't already tools out there that will do the job. DRY etc etc
I think you are drawing a false distinction between "technical decisions" and "business decisions". In the context of a business, what technical decision doesn't affect the business in some way?
The PM's view is the business's view colored by the PM's preconceptions. Good PMs will defer on technical decisions and be firm on business decisions. Bad PMs won't.
If developers have a tough time with developing Windows Forms and would rather use Python daily, they should found a start-up and create a business that is inline with a developer's view.
That's one way to do it. Another good way is to communicate with the PM/business in language that speaks to them (cost/savings, time to build, maintenance costs, etc.) and make the case for Python (or whatever).
Interesting thought: * Poor developers will pick their technology irrespective of the problem at hand. * Good developers will pick the most appropriate tool given the problem at hand. * Great developers look at the problem at hand and write whatever tools from the ground up they need in their chosen technology to make it happen. (See: 37signals with Ruby, developed Rails. Django with The World Company, etc.)