I’ve been trying to figure out how it is that a business goes as far awry as the mess that I’ve gotten involved in. Somehow, this business has become so deeply convinced of its own BS that it, like the Ouroboros, is devouring itself yet constantly recreating itself in its same image.
See, to me, this is all bizarre, because I have a staunch animosity for dishonesty in the business world. For anyone on my business team to lie to me is not just a personal offense, but fundamentally self-destructive and tatamount to theft from the shareholders. If there is bad news, I want to hear it and I want to hear it as soon as possible. If I have lost touch with the world, I need to be brought back into touch — forcefully, if need be. And if I (or anyone) can’t be brought back in touch, they need to stop hurting the company.
So, given that as my opinion, and given that many developers I’ve spoken to have had the exact same opinion, I couldn’t account for the preponderance of the exact opposite mindset in the business world.
My new theory is that development lives in the real world, where lies have consequences. If you say code does something, and it doesn’t, people will notice soon. If you say you can deliver something, and you don’t, people notice. If you don’t have the skills you said you do, then it will be obvious in a hurry. All of these statements, notice, are subject to empirical testing. And that’s the reality of computer development.
The rest of the business world lives in the business world, where lies can be managed and spun. Therefore, developers work poorly in the business world, because we have this weird “honesty” concept ingrained in us through many, many times of being wrong and being caught. On the other hand, the rest of the world accepts all statements as lies and produces nothing but lies, because anything else might have negative reality-based consequences (like the unfeasibility of a deadline implying the inability to deliver). So all PMs, many QAs, and some BAs are all based in a reality where the highest priority skill is to be able say things that make the listener happy, without threatening future happiness in the same category, even if that means driving the listener into a world-view completely disconnected from the real world.
But that’s not the worst of it yet! What this means is that the preference between certainly making someone slightly mad now and maybe making someone very angry later actually falls to the latter. To be clear: to PMs, some QAs, and some BAs, it is better to lie to someone now and try to cover up the tracks than it is to address an issue now and come to an honest resolution. So, if there is a problem, it is in the PM/QA/BA’s best interest to pretend there isn’t and (as quietly as possible) try to fix the problem — if reality can’t be drawn into alignment with that fiction, the next best thing is to try to aviod having that fiction be tested in any real way.
And, the sad part is, that works most of the time.
It’s not surprising, then, that productivity-increasing IT management systems are all based around natural accountability and deliverable management. The counter-strike in this B.S. arms race was the invention of “paper deliverables” and “sign-off deliverables”. Now the productivity-increasing IT management systems are fighting back a flood of nonsensical and nonbinding documentation in order to remove this lie-ridden junk as a potential deliverable. That’s the core of Scrum, as well as the corresponding American “No Fluff, Just Stuff” IT management movement that have such momentum.
Popularity: 7% [?]
