Project Manager's View vs. Developer's View(knowing.net)
knowing.net
Project Manager's View vs. Developer's View
http://www.knowing.net/index.php/2010/03/16/project-managers-vs-developers-view/
27 comments
I'm actually somewhat surprised at how managers react to JSON. Every time I mention it, I can sense that they want to say something along the lines of "take a shower, hippie".
Interesting. One of my developers asked me yesterday if I wanted "JSON, XML, YAML or Python pickle" as Django Piston delivers all of them. I suppose I am not enough PM and too much developer. ;)
I am looking forward to EC3
Personally, I still look back wistfully to the days of EC.
It's a merging of EC2 and S3. They've made a huge breakthrough and now all the data on EC2 instances is massively scalable and magically replicated to 3 datacenters.
I would move Windows Forms to a higher level of project manager anxiety; this chart may have been correct in this regard 10 years ago but most PM's I've worked with are afraid to do anything that isn't "on the web" (including mobile apps) anymore.
What's the y-axis supposed to represent?
The maximum total desire to work with some technology.
from the developer's perspective, I gather. However, the lower x-axis already indicates this, so the curve is still poorly defined.
ROI
I would expect that at least a few HN readers are like me: past developers, who now spend the bulk (if not all)of their time managing projects. In response to questions about the vertical axis, my answer is that from a PM perspective, it's the measure of how much the developers want to play with the latest technology. From a developer perspective it's the measure of "perceived benefit" from applying a specific technology. Having seen a lot of sexy technologies fall by the wayside over the years (often because they turned out to cause more problems than they solved - yes I'm talking about you, CORBA), my sympathies are with the PM view. When I was a young programmer, we had similar "discussions" with the old guys about the merits of C versus COBOL/VSAM versus RDBMS/client-server versus dumb terminals. As far as I'm concerned, if you can show me (the PM) a quantifiable benefit of using a new technology, I'll consider it. But in a lot of cases, the benefit seems to be "it's cool, and I want to try it." I sympathize with you, but that's not enough to justify the risks I'm taking on by using a new technology.
What developers need to always understand is that the PM's view is the business's view.
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.
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.
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.)
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?
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 would say that a better way of phrasing it would be: "Great developers solve the problem at hand in spite of the tools that are available".
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?
All very valid points. I don't disagree, but I was certainly interested in being more simplistic, namely because the article was.
What developers need to always understand is that the PM's view is the business's view.
I've never understood this bright line boundary between the patchwork of people that make up a technical group, and the patchwork of people that make up a business group. Presumably, the technology being developed is part of what makes the business viable; it isn't just a bunch of people wanking off in text editors on company time, while the grown ups -- the business folks -- do everything that earns money.
It serious just seems like an artificial division to excuse the two groups for not listening to each other.
This becomes even more painful when you are one of the people who wants to be involved in whatever makes up this nebulous "business side", and are told to fuck off back to your toys.
My view: the business is everyone's business, and any time you start developing bright line boundaries to either protect turf, enforce a hierarchy for its own sake, or excuse non-involvement, the least of your problems is one of your techies wanting to play with technology that seems superfluous to the untrained eye.
I've never understood this bright line boundary between the patchwork of people that make up a technical group, and the patchwork of people that make up a business group. Presumably, the technology being developed is part of what makes the business viable; it isn't just a bunch of people wanking off in text editors on company time, while the grown ups -- the business folks -- do everything that earns money.
It serious just seems like an artificial division to excuse the two groups for not listening to each other.
This becomes even more painful when you are one of the people who wants to be involved in whatever makes up this nebulous "business side", and are told to fuck off back to your toys.
My view: the business is everyone's business, and any time you start developing bright line boundaries to either protect turf, enforce a hierarchy for its own sake, or excuse non-involvement, the least of your problems is one of your techies wanting to play with technology that seems superfluous to the untrained eye.
The project manager's view includes both the business side and personal fears/biases. And as people are wont to do, a PM will disguise personal doubts as business decisions.
What is also never mentioned is that what employees desire is as much the business of a business as other things.
But suppose we buy 100% into the maximizing shareholder mantra.
If you have programmers that are interested in these technologies, your shop is probably doing some interesting work (since otherwise these programmers would not have bothered working at your shop). In this case, careful leveraging of new technology (that is, choosing something that's not too far right on the curve for your purposes) can give you a leg up on the competition, since the programmers are happier and you can offer things that the competition cannot.
A manager that avoids new technologies in this context is not doing what is good for business.
It is a false dichotomy that what is good for programmers is necessarily unrealistic or bad for business.
What is also never mentioned is that what employees desire is as much the business of a business as other things.
But suppose we buy 100% into the maximizing shareholder mantra.
If you have programmers that are interested in these technologies, your shop is probably doing some interesting work (since otherwise these programmers would not have bothered working at your shop). In this case, careful leveraging of new technology (that is, choosing something that's not too far right on the curve for your purposes) can give you a leg up on the competition, since the programmers are happier and you can offer things that the competition cannot.
A manager that avoids new technologies in this context is not doing what is good for business.
It is a false dichotomy that what is good for programmers is necessarily unrealistic or bad for business.
It would be pointless to argue that personal fears/bias are not part of the decision making process. But by the same token, I think you must recognize that programmers also have biases, one of which is to try new things.
There is definitely business value in using technologies that attract and retain the best developers. But that benefit must be weighed against costs like the difficulty of finding trained programmers, instability of immature technology, etc.
There is definitely business value in using technologies that attract and retain the best developers. But that benefit must be weighed against costs like the difficulty of finding trained programmers, instability of immature technology, etc.
> difficulty of finding trained programmers
This one in particular always really annoys me. I get shot down all the time for this reason and I really don't recommend anything a competent developer couldn't pick up in a week. That means no FP and no 'interesting' architectures because programming methodologies and different architectural approaches can't be picked up without real effort. That's fine, I'm okay with that and I don't lobby for it even if I do think it'd reduce the code base by 60%.
Shooting me down for hireabilty because I want to use yui3 instead of jQuery? Forbidding the use of SASS instead of CSS? If they can't pick it up, YOU DON'T WANT TO HIRE THEM.
This one in particular always really annoys me. I get shot down all the time for this reason and I really don't recommend anything a competent developer couldn't pick up in a week. That means no FP and no 'interesting' architectures because programming methodologies and different architectural approaches can't be picked up without real effort. That's fine, I'm okay with that and I don't lobby for it even if I do think it'd reduce the code base by 60%.
Shooting me down for hireabilty because I want to use yui3 instead of jQuery? Forbidding the use of SASS instead of CSS? If they can't pick it up, YOU DON'T WANT TO HIRE THEM.
Honestly, I do sympathize with you. There have been many times during my career when I felt there were clear benefits to using a new/less widely used technology. At one time that meant using C instead of COBOL. Unfortunately, my arguments have rarely survived the "what if you get hit by a bus" counter-argument. If you develop something using a whiz-bang technology, and then suddenly you are not there (you get a great job offer based on what you have created), who is going to support/maintain your creation while "they" find another wizard? The ancients solved the problem by laming their smiths.
> What developers need to always understand is that the PM's view is the business's view.
In theory yes. But I just finished reading a "test strategy document" from a guy whose title is "test strategist" and who doesn't write any code. So I am burnt by reality :-)
In theory yes. But I just finished reading a "test strategy document" from a guy whose title is "test strategist" and who doesn't write any code. So I am burnt by reality :-)
pm view in big corp is his ass. Period.
Anything that might risk his name apearing on anything that stands out, be it a minor note from legal or a note in the rolled back launchs in the sysadm journal and he sticks with windows forms.
Anything that might risk his name apearing on anything that stands out, be it a minor note from legal or a note in the rolled back launchs in the sysadm journal and he sticks with windows forms.