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.
12 Comments
And the sad part is, that this movement too will fail. It’s hard to remember it at this remove, but the “total quality” concept had some real meat on it’s bones when it first started out. It had other problems, but it wasn’t the buzzword bingo magnet it is today. Not unlike Multimedia. Object Oriented managed to keep some semblance of it’s original meaning, but only by the skin of it’s teeth.
Any system can be gamed. Any system has superficial attributes (simply by having a surface, by having something that isn’t inside) which can be duplicated even while, or maybe especially while, missing the core concepts. Any term can become a buzzword due to misuse/overuse/redefinition.
I strongly think there are a number of people kicking around who don’t think, or at least act like, words don’t really have meaning. There are good words, and bad words. You want to apply good words to you and people you like, and apply bad words to people you don’t like. Skating into the political realm, notice how words like ‘democracy’, ‘terrorists’, and ‘liberal’ get used. Take a good long look at the growing ‘Bush is a liberal’ chorus from the far right. The only way this makes sense is if you accept the tautaulogy:Liberals are badBush is badTherefor, Bush is a liberal. Of course, pointing out the minor logical flaw here simply singles one out as a member of the reality based community, and thus presumptively a commie mutant traitor, er, american-hating liberal elitist traitor.
I don’t know what we can do about this. It has the feeling of a deep seated human nature sort of thing- something where eliminating it would make eliminating sexism or racism or war look trivial by comparison. We’re talking about changing, not just what people think, but fundamentally how people think. In strange aeons even death may die- but this one will take even longer than that. I suspect it’s genetically based- or at least has a subtle genetic component. And I wouldn’t definately rule out that it arises from the same deep language structures that give us poetry- language as emotional manipulation instead of symbolic manipulation.
“animosity for dishonesty … many developers I’ve spoken to have had the exact same opinion”
So some developers think themselves staunchly honest and think less of their co-workers?
Maybe when you speak to the “PM/QA/BA’s” they will “have the exact same opinion” of themselves but think developers are less staunchly honest.
Yes — not just some but many developers, particularly in large corporations, find the business people they work with deal less with reality and more with perception. They deal in soft deliverables, politics, and other social realities which aren’t necessarily reflective of the code and its functionality. To this extent, they appear dishonest to the development staff.
In my time as a developer and technical lead, I’ve encountered many accusations against developers, many of them very legitimate. Developers are often hyper-optimistic or hyper-pessimistic. They often wander from what the customer considers useful technology, or over-architect what should be a simple solution.
Interestingly, though, I haven’t encountered people who think developers are flat-out lying. Maybe they just won’t tell me, since I’m associated with development. Maybe I’ve just not been in a place that is dysfunctional that way. Maybe it’s because one of the first things I push for is transparency-increasing technologies like continuous integration and FIT. But I can confidently say that in my experience, I have not encountered a development staff with a reputation for dishonesty. And, as I said in the OP, I think it’s because developers have their BS called pretty fast: when the code doesn’t work like they said it should work, there’s no spin that will change that reality and its reflection upon their BS.
Maybe, contrary to your OP, it’s so difficult to call developers’ BS that the “PM/QA/BA’s” can’t tell whether they are dishonest or hyper-optimistic.
Maybe when people are being dishonest with themselves we call them hyper-optimistic.
Maybe “PM/QA/BA’s” are just less inclined to call other people dishonest.
When I’m saying ‘hyper-optimistic’, I mean that they are underestimating the amount of time something will take, etc., etc. Estimations are notoriously difficult, and the lack of self-reflection and self-criticism among development teams on this point really aren’t doing anyone any favors. Effectively estimations — and effective management of bad estimations — are one of the key challenges for a technical lead.
That time estimates can (and often are) off for developers is not something I’m going to argue, but I do note that (at least in iterative structures) it doesn’t take too long before a time estimate (and, moreover, the pattern of hyper-optimistic estimates) becomes very obviously wrong.
Where do you see developers being dishonest without being caught?
Particularly at the time this was written, some of the QAs and both BAs I worked with were pretty clear in identify the PM’s dishonesty — that is, points where the PM’s assertions did not correspond to any known or reported reality. So I don’t think that’s it.
I’d just like to follow up on some themes that previous repliers had mentioned. Namely, about large organizations and reality vs. games.
My previous employer, a company with a name that starts with ‘H’ (think Iraq). A quite big company.
In these big companies, corporate politics drives essentially all actions. Only some politics is related to the commercial activities of the company; all the rest (most of it, say 80%) is directed toward managerial advancement.
You have very senior managers who are jockying for the next available CXX position (i.e. CIO, CFO, etc.), and all their energies and decisions are devoted to that end. Their direct reports are tasked with making this promotion a reality. This has a ripple-down effect; essentially all employees of the senior manager are working toward getting the senior manager promoted to the next position. The employees may not be directly aware of it, but that is what they are doing.
Now, some of the activities of the employees must be directed to commercial activities, or else the corporation would collapse. But, in my experience, the percentage of activity devoted to commerce is not all that large. Certainly not more than 50%. The rest of the activities are devoted toward advancing the senior manager. In this sense, the definition of success is interpreted by political expedience and not by quantitative means such as revenue generated.
So, given that most activities are governed by political expediency and ambition, should it surprise us that there is so much dishonesty in these environments? Its actually a surprise that these companies survive at all.
There’s a kind of inertia associated with large companies. A considerable amount of this non-productive political activity can be tolerated before the company begins to suffer — we’re talking many years. Before that happens, the senior managers can be promoted, can establish their own industry reputations, and can then abandon the company before the death spiral sets in.
Sorry for the negative and cynical tone to this reply, but its the truth.
If you want to advance in a technology company, get into a large corporation with active politics and ignore technology. If you want to actually do technological things (like, I don’t know, ship quality software) join a small company where survival is actually directly linked to shipping quality product.
Dear Robert,
Why are you arguing with this Isaac Gouy guy?
He is only commenting either because he is/was a PM,BA,QA and decided to take your post personally or because he enjoys playing a victim and is out looking for someone to accuse as his victimizer…probably both. But in any case what are you gaining by indulging him?
His responces are sarcastic and have no examples or justifications like yours do. When I read those “Maybe…” statements I hear the voice of an indignant child in my head.
Your blog has been a place for intelligent debates and conversations and I suggest you maintain its integrity by explicitly requiring justifications and examples for all arguments or declaring them invalid and ignoring their presence.
Love,
Me
p.s. I know that the thought of converting one of the very people who frusterate you in this world makes your heart swell…but you have to wait for the people who ask for your help or who are at least willing to listen to your well thought out responces. You’re wasting your infinitely valuable time on everybody else.
alw wrote “When I read those “Maybe…” statements I hear the voice of an indignant child in my head.”
The indignant child is in your head, not mine.
alw wrote “…is/was a PM,BA,QA”
Not true.
alw wrote “enjoys playing a victim”
This seems to be a personal attack – a little strange that it would come from someone espousing intelligent debate and conversation.
Robert wrote “Where do you see developers being dishonest without being caught?”
If they weren’t caught (and it wasn’t me) then how would I know?
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.
Thought you might find this article interesting: http://davidmaister.com/blog/213/ It refers to a study that concludes that MBA students are more likely to cheat than other students.
Here’s a quote:
Okay — so we agree to at least one basic principle of the OP: namely, that developers are subject to being caught in ways that are rather unique to their position (namely, what they assert needs to be demonstrated in code). Is that fair?
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.
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.
My objection is simply stated – this is no more than tribal special pleading – developers are honest and accountable, PMs are dishonest and unaccountable (aka me good, you bad).
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”?
3 Trackbacks
[...] Basically, Fit fills a critical communication void: the communication of what the software should do and what it does do. I am a huge advocate of transparancy, since my experience has shown a lack of transparency to be the primary cause of breakdowns in development environments (e.g.: this on “soft deliverables” and other fun). Even better, this is transparency at the level business people are used to dealing with: electronic paperwork. You can take whatever documentation your people like to use, massage it very gently, and then plug it into your automated testing framework by creating a class that (even in Java!) is not even 100 lines. [...]
Raganwald…
Sorry for the short post, but I was checking out the blogs which link back here, and I discovered this post over at Raganwald. The short form is that the author tried to write a program that would help people at least be aware of when projects are 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.” (Theory of Business) [...]