Slashdot Mirror
In Defense of Project Management For Software Teams (techbeacon.com)
mikeatTB writes: Many Slashdotters weighed in on Steven A. Lowe's post, "Is Project Management Killing Good Products, Teams and Software?", where he slammed project management and called for product-centrism. Many commenters pushed back, but one PM, Yvette Schmitter, has fired back with a scathing response post, noting: "As a project manager, I'm saddened to see that project management and project managers are getting a bad rap from both ends of the spectrum. Business tends not to see the value in them, and developers tend to believe their own 'creativity' is being stymied by them. Let's set the record straight: Project management is a prized methodology for delivering on leadership's expectations.
"The success of the methodology depends on the quality of the specific project manager..." she continues. "If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives -- all within the prescribed budget and timeline. Denouncing an entire practice based on what appears to be a limited, misaligned application of the correct methodology does not make all of project management and all project managers bad."
How do Slashdot readers feel about project management for software teams?
"The success of the methodology depends on the quality of the specific project manager..." she continues. "If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives -- all within the prescribed budget and timeline. Denouncing an entire practice based on what appears to be a limited, misaligned application of the correct methodology does not make all of project management and all project managers bad."
How do Slashdot readers feel about project management for software teams?
I've seen a bad project manager deliver bad products.
I've seen the other end of the spectrum where the PM worked with the devs, and was an all round good project manager.
Strangely, when a team works together, yo get a better result. When the PM is a dictator, you get an entirely different result.
The worst is when there is no project management. Things never get done, or you later find out that 6Month late project was because a new hire decided to swap X out for a
Actually I take it back. The worst is when the Shouty boss decides that shouting is project managing. Then the devs will deliver a mish-mash of shite built on a foundation of bitterness
YMMV
Signature v3.0, now with 42% less memory usage.
You know, I'm a bass player (when I get the time). Nothing even close to, say, Flea, mind you, but decent enough. Ever heard the bass player jokes? We're dumb, can't play, have no talent, you name it. Why? Because there's a lot, an awful lot, of really, really crappy ones. Why? Because of how bands start out. The guy who can play guitar well does lead, the guy who can play passable does the rhythm and the one that can barely coordinate fretting and strumming gets bass. Because you can't fuck up too much there, it's easier and with a bit of luck nobody notices when you suck, can't hit a note or be in time. Bass is easy to pick up, hard to master, I can tell you, but it's easy to not fuck up too badly early on. And if you fuck up, someone's gonna pick up your slack and play the bass for the records.
Same with project management.
When you look at the resume of project managers, you find that many of them had a lot of hats so far. Not necessarily even as part of a programming team or a project. But project management is easy, at least to pick up. You don't really have to produce much. You have to "coordinate", and with a hint of luck the team will be good enough to pick up your slack and compensate for your shortcomings.
That is not true for all project managers, mind you. Like it's not true for all bass players. Some get there because they really want to do it and they are really, really good at it.
It's just the army of really, really crappy ones that you encounter throughout the years that color your vision badly.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I know a couple of the PM's I've worked with on software projects in the past will be angry and disappointed at the subject line but I've never seen one that demonstrably added value to a software project/product I've been involved with - most have been detrimental to the overall effort. I can say that I do know a number of PMPs that are critical to hardware and marketing programs and have been vital to their success - I'm leading to a conclusion here.
First off, today it seems like getting a PMP certification is something somebody gets when they've been laid off and there are no jobs on the immediate horizon. I know that seems cynical but there seems a lot of truth to the statement - if you can demonstrate that you've worked slightly more than two years, take four or five courses and write an exam? In less than a month and a couple of thousand you too can have "PMP" on your LinkedIn profile.
I've taken the courses (through work) and they do have some value for general knowledge and if you are going to be managing a project which results in a physical object. Software is an entirely different beast and I believe it's impossible for really anybody to really properly plan out how a project will go. Unlike planning a piece of hardware, the required skills with efficiency are somewhat more nebulous (ie I can state with a high degree of confidence how many bricks at a certain quality level can be laid in an hour - I can't do the same for lines of code, it's highly dependent on the coder, development tools, libraries as well as pre-requisite work being done). To be fair, it's extremely hard to properly quantify coders - which makes planning and managing their progress difficult.
The best team lead I ever had, lived by the following set of rules for every project:
1. Set an expectation for the number of lines of working, debugged and documented code per day to something which seems ridiculously low (in his case it was 10 lines per day per coder) but is actually very realistic when you look at actual historical progress of the team/organization.
1.1. Plan contingency time at the end of the project (he liked 30% of the total project time) for new requirements and unexpected issues.
2. Coders work four days a week with one day for training and meetings. See "Management Time vs Maker Time".
3. Management can't talk to coders about their work. Ever.
4. Requirements/Specifications can't change through the project. That's what the contingency time is for at the end of the project.
5. Have an established test plan - In talking to him recently, he now insists upon implementing automated unit and functional tests that the entire software corpus runs through before any major release.
6. Base the plan and milestones on a reverse of the 80/20 rule - look doing what is going to be needed for the what is normally the last 20% and do it first
6.1. Pushing the requirement for the final UI design to the end of the project. Let marketing pay for prototypes and implement them at the end of the project. If the coders need a UI for testing, then they can cobble something together (and I know of two products where this became the final UI).
7. Accept that shit happens - I still get teased about putting in the statement "if (i = 1) {" thirty years ago in one of our projects which was discovered in testing in which the code mostly worked with the exception of one corner case that bugged a number of us (including him) into spending a week trying to figure out what the problem was.
You don't need a project manager to run a software project following these rules - you need a good, knowledgeable and forceful team lead.
Mimetics Inc. Twitter
Sounds like she is very good at projecting a persona, telling people what they want to hear, and promoting herself--someone to be avoided at all costs if you're interested in actually getting any work done.
Il n'y a pas de Planet B.
> Outside of that, why WOULDN'T you write a section of code the simplest and most straightforward way possible?
* Because it doesn't report errors.
* Because failures corrupt critical data.
* Because it does not sanitize its inputs.
* Because it consumes far more resources.
* Because it's not testable without the
* Because it's not secure.
* Because "simple" and "straightforward" does not necessarily mean "intelligible".
* Because it requires a complex set of upstream features which have proven unstable.
The list goes on. Balancing the factors to produce robust, reliable, performant code can become quite a challenge.
> Not every task actually benefits from creativity!
Indeed! At my own company, every week somebody is costing us time and money by trying to come up with a creative way to do something rather than looking up how others have done it successfully for decades.
Most recently, we needed to handle many concurrent TCP connections. We wanted to fire off a request, send other requests on other sockets, then come back later and read the responses, asynchronously. This is instead of sending a request, waiting for the response, then sending another request. Developers creatively brainstormed different ways to do this, coming up with mostly very bad solutions. I pointed out that many concurrent TCP connections has been some many times before, sometimes by people much more knowledgeable than us. The Apache web server has multiple different multi-processing modules to choose from, with many sources describing how each works, and the advantages / disadvantages of each.
Last week they were coming up with creative ways to script getting the IP address of a newly launched AWS instance and adding its IP to the whitelist of another security group. I pointed out we're not the first company to want two AWS instances to be able to talk to each other. Perhaps we should check the documentation. Sure enough, AWS security groups allow you to whitelist access from another security group - no need to get the IP at all. Just click the button once, which then allows all instances in the scaling group to access the protected resource.
I've explained to them that there is a well-defined way to represent many-to-many relationships in SQL databases, known-good ways to represent hierarchy, etc. We don't need to creatively invent any of this.