[beatpanda]

I don't identify with this at all. One of the first things I started asking for at my most recent job was a better, more clearly-defined process so that we knew exactly what we were building, what it needed to accomplish and what does "finished" mean. I largely got what I was asking for. Its made our engineering team a lot more focused and enabled us to deliver faster than we were before. It also makes it easy to figure out what to work on next.

Maybe the difference for me is that software engineering is my job, not my lifestyle or identity. I don't know.

[greenyoda]

"so that we knew exactly what we were building, what it needed to accomplish and what does 'finished' mean"

That only works when the people who are asking for the software know what they want. In the situation described in the article:

"The one where you try to replace an expert user’s years of experience and intuition with software. What started out as a vague and wooly requirement, soon became a monster as we started to dig into it."

In my experience, the business people aren't good at turning vague and wooly requirements into precise specifications for software - they're not trained as logical thinkers. Usually, that job falls on the developers, who will try to clarify the requirements until they have something that's precise enough to be translated into logically consistent code. This may involve a lot of trial an error, since trying to extract the requirements from the business people is a non-linear process (e.g., they can change their minds on what the spec is, and a seemingly small change in the spec can have a large effect on the architecture).

[mwfunk]

I like having a certain amount of process as well, but I interpreted the article as being more about the dynamic between the developers and the PMs than process in general.

In my experience, different orgs use PMs in different ways. The most positive experiences I've had has been with PMs who were there to facilitate communication, get people unblocked, keep track of requirements and big picture stuff, and in general to help people out and worry about certain things so the engineers don't have to.

I've also had bad experiences with PMs in other orgs. In the bad cases, the PMs are used by upper management solely to keep an eye on everyone, not to help them. These are the places where the only time you deal with PMs is when they summon you into meetings to explain why you're not done with something yet, or they pop into your office to give you a list of items and want to know which ones are done and what's the ETA on everything else.

When used appropriately, PMs can be a godsend and no one resents having to deal with them because they make everyone's jobs easier. When used inappropriately, all they ever do is go around and harass people with stuff like, "is X done yet, and if not, what's the ETA?" When used in that capacity, that means they been drafted into a different role where they're being used by higher-level management to stay on top of everyone and roll up daily or weekly reports that the higher-level managers then send up to their managers to make it look like they're in control of the situation.

When used extremely inappropriately, you will see a (anti)pattern of gradually increasing granularity in how they track people. They go from tracking high level goals and milestones to tracking people and projects with increasing levels of granularity. They go from tracking engineering time in terms of months or weeks to days or hours.

Eventually this granularity crosses some threshold of usefulness, and it starts having detrimental effects on the results. Things like refactoring or code cleanup or really just doing anything that is not working on a specific new feature becomes verboten. People start exaggerating their time estimates to give themselves wiggle room, or to sneak in extra time for critical maintenance work that is not associated with a shipping feature. Eventually everyone's just lying to everyone about everything, and the constant meetings and "are you done yet?" pop-ins become pointless rituals that waste everyone's time but continue happening with greater frequency.

[outworlder]

Maybe the difference is also what you are working on, or the stage the project is in. Or the level of understanding of the business requirements from everyone involved.

However, this case appears to be micromanagement, pure and simple. Micromanagement is "way too much of a good thing".

EDIT: Don't forget the pie-in-the-sky requirements. If you have sane and straightforward requirements, then you can usually break them down without too much drama. But, if they are that simple to break down, should they even be?