Now you have given more examples of developers being dishonest and unaccountable and yet you persist with your original argument that developers are accountable?

PMs/QAs/BAs/developers are accountable to the extent which they are held to account.

Robert wrote: “developers are subject to being caught in ways that are rather unique to their position”
You haven’t tried to demonstrate that PMs are /not/ subject to being caught. In fact you provided an example of a PM being caught!

“some of the QAs and both BAs I worked with were pretty clear in identify the PM’s dishonesty”

So what did they do about it? The word for their silence is complicity.

a blatant lack of “Open Honest Communication”?

From personal experience I know some developer worked for some other company on the days he was supposedly working for our company at home, more than one developer who spent their cubicle time in a large corporation working on software for some other company, a developer who never got close to delivering the software they confidently and repeatedly promised, … the damage is still done even if they are eventually caught.

Ah, okay. These problems fall into one of two categories: contractor problems, and oversight problems.

Insofar as a developer is acting as a contractor, they are a business person without the same accountability which I was talking about in the OP — they are basically acting in that same role I’m talking about, and they are subject to (indeed, encouraged to) the same kind of bad behavior. These are different than development problems in that they can’t be held accountable to code: which hours you worked for which client can’t be unit tested or shown in a demo. I will certainly agree that there are shady contractors out there a dime a dozen, and double-dipping is a key example of that.

(Another great example is the contractor who over-sells themself. I once had a person on one of my teams who came on board to a Senior Java developer role, and to hear him talk, he practically wrote the JVM. When we got him on board, he couldn’t do anything. Couldn’t even get a unit test to run. It was horrific. Thankfully, we could identify the problem within a week or two by asking to see functioning code. When he came up with nothing, it was obvious he was a scam artist, and we could give him the boot right away.)

The other issue you have is this one: “a developer who never got close to delivering the software they confidently and repeatedly promised“. This can happen for a variety of reasons: sometimes it’s an unaccountable developer, but sometimes it’s not.

I once subcontracted out a piece of work which had the same problem: it was a definite learning experience, and I won’t allow it to happen again. The problem (at least my case) was a lack of oversight, and an unwillingness to accept the reality I was seeing. I didn’t hold the subcontractor accountable to code, because I knew the subcontractor well and implicitly trusted him to deliver on what he said he would. At that point, without the restraint of accountability, he fell into the same pattern that I was describing in the OP. Besides which, this particular subcontractor had no professional development experience, which means that he was never “trained in”: he never had the experience of stretching the truth and then being smacked down through code accountability.

On the other hand, failure to deliver can also be a business problem. I’ve seen developers working on an internal project who got their reputation blasted for failing to deliver — but when one looked at what they were dealing with (or, better yet, took over as tech lead and dealt with what they were dealing with), they never really had a chance. Specs were coming in too quickly on the front, and code was slogging slow through the business process on the back side. Even if they worked late and long hours (and they did), they could just barely deliver code fast enough — but then they could not release it because of stalls after their pipeline stage. They got blamed for failure to deliver, but it was really a business process (and therefore a management problem) which killed them.

Robert wrote “…points where the PM’s assertions did not correspond to any known or reported reality”
I have the impression that you are now talking about a particular PM singular rather than PMs plural. One bad apple?

In that particular point, I was talking about a single PM. However, I’ve seen that behavior in various business people I’ve worked with both before and since posting this analysis.

I’d like to point out that I’m not asserting it’s inevitable that people in the business community are going to be like this. It is certainly possible to find contractors/PMs/QAs/BAs with integrity who are willing to say “I don’t know” and “That’s not possible”. If these people are also good at what they do (and they often are), then they are worth their weight in gold.

However (and this gets back to my comment on the ‘Raganwald’ post), even they don’t have that same accountability that developers have, and they are often fighting against a business culture which tempts them away from that position.

Here’s a quote:

The study suggested that MBA students were more likely to cheat than others because they were focused on “getting the job done, versus how they got it done. They will suggest, in the business world the emphasis is on getting the job done at any cost.”

From personal experience I know some developer worked for some other company on the days he was supposedly working for our company at home, more than one developer who spent their cubicle time in a large corporation working on software for some other company, a developer who never got close to delivering the software they confidently and repeatedly promised, … the damage is still done even if they are eventually caught.

Robert wrote “… points where the PM’s assertions did not correspond to any known or reported reality”
I have the impression that you are now talking about a particular PM singular rather than PMs plural. One bad apple?

Once upon a time, I worked for a manager who denied he’d asked for the work product – even when shown the document he’d signed asking for that work product. None of the other managers I’ve worked with have behaved in that way.