Is Project Management Killing Good Products, Teams and Software? (techbeacon.com)

New submitter mikeatTB writes: "For software development, no significant developer activity is predictable or repetitive; if it were, the developers would have automated it already," writes Steven A. Lowe, Principal Consultant Developer at ThoughtWorks, via TechBeacon. "In addition, learning is essentially a nonlinear process; it involves trying things that don't work in order to discover what does work. You might see linear progress for a while, but you don't know what you don't know, so there will be apparent setbacks. It is from these setbacks that one learns the truth about the system -- what is really needed to make it work, to make it usable, and to make a difference for the users and the business. In other words, the dirty little secret of software development is that projects don't really exist. And they're killing our products, teams, and software." Lowe continues: "Projects, with respect to software development, are imaginary boxes drawn around scope and time in an attempt to 'manage' things. This tendency is understandable, given the long fascination with so-called scientific management (a.k.a. Taylorism, a.k.a. Theory X), but these imaginary boxes do not reduce underlying complexity. On the contrary, they add unnecessary complexity and friction and invite a counterproductive temptation to focus on the box instead of the problem or product. This misplaced emphasis leads to some harmful delusions: Conformance to schedule is the same thing as success; Estimation accuracy is possible and desirable enough to measure and optimize for; The plan is perfect and guarantees success; The cost of forming and dissolving teams is zero; The cost of functional silo hand-offs is zero; The bigger and more comprehensive the plan, the better; Predictability and efficiency are paramount."

Comments

Eisenhower

[Strider-]

To quote Dwight D. Eisenhower, "In preparing for battle, I have always found that plans are useless but planning is indispensable."

If you go into a major project without some sort of project management, it's not going to end well. However, the management of the project needs to be flexible enough to adapt to the changing environment. Decent project management will see when things are under resourced, and help to fill in those gaps (if possible), and should keep the project going in the right direction.

Re:Eisenhower

[Zaelath]

Decent project management will see when things are under resourced, and help to fill in those gaps (if possible), and should keep the project going in the right direction.

That's (probably) more mythical man month PM bullshit right there.

Generally in a software project "under-resourced" means the milestones aren't being reached, which either means you have bad milestones, bad requirements, or bad coders.

Adding another 5 coders to part of the project doesn't make it go faster if the first one has written a pile of garbage and it needs to be unpicked or more likely the new coders are rubbish and no one wanted them on their project, so they're available to "help".

Most PMs I've met have been great people with great PM skills, and no clue if what a coder is telling them is accurate. I'm sure there's some counter-example with great code assessment skills, but that doesn't make them representative of the class.

Re:Eisenhower

[Strider-]

Generally in a software project "under-resourced" means the milestones aren't being reached, which either means you have bad milestones, bad requirements, or bad coders.

I guess I didn't make myself sufficiently clear, and you hit the nail on the head. By resources I was meaning not just people, but equipment, tools, requirements, knowledge, plans, or is it just bad milestones to begin with. Adding more people to a failing project is a recipe to make it fail faster, the solution is to figure out what's going on early so the problems can be resolved.

Re:Eisenhower

[Zaelath]

Ah, fair enough. I've seen at least one manager kill a project at birth since it was not possible to do, but that's pretty rare.

Also, I'd forgotten the absolute worst PM trend; project is going too slowly, we need a daily meeting that we'll pretend is 15 minutes, but is actually an hour and probably subtracts 2 from the day with prep and recovery.

3 things that make project management hell

[nimbius]

1. project managers that graduated from the school of flagellation. the ones that think assigning a firm date to every goal is the only way to ensure it gets completed, and are willing to waterboard you for not adhering to the holy calendar. some of what we do in systems engineering -- like deprecating old systems or rolling out your cloud provided buzzgasm solution -- is highly technical. if you're not willing to draw diagrams or at least document how and why we arrived at some of these goals, youre just another manager.

2. project managers that ignore dependencies. sometimes other teams need to get involved to accomplish a given task or objective and if youre not willing to make the call, then who is? securing time from the beleaguered network guy, the storage zombies, or the NOC is technically under your purvey. if we make it all the way to the calendars release date and you havent done the needful when it comes to taking to other teams and understanding the business structure, then we can hardly be blamed.

3. companies that insist on contract-based project managers. they arent around long enough to learn the business or the systems in place, so they have very little incentive to participate fully in the project lifecycle. these shitlords get away with floating from company to company and doing very little at all.

Does nobody read anymore?

[bobbied]

"The Mythical Man-Month" by Fred Brooks.

This should be required reading once a year for ALL direct and indirect management of any engineering or software development team.

Again with the "Oh, Look at what I found, managing complex tasks is hard!" How many times will we be blessed with the same insight that Mr. Brooks put on paper way back in the 1970's? My guess is "just once more!"

Price in status reports

[sfcat]

The problem is that upper management doesn't understand that status reports have a non-zero, non-trivial cost. When a project gets into trouble, the number of status reports and meetings increase, which surprise surprise, slows down progress. Also, software development is non-linear for at least part of any non trivial project. Refusing to accept that fact has caused problems for decades. Sometimes as a developer, it feels like management is working against us. Does any of that sound like a useful part of running the business?