Honest Communiction: The Quote
If your organization punishes honest communications and you start to communicate honestly, you’ll be destroyed.
That’s a quote from Kent Beck I just came across on CoachSpot.
I agree with the sentiment, I disagree with the fervour.
Dishonest communication is frustrating and counter-productive
Many programmers, at least most of the good ones, love what they do, at least in theory, and would write programs if they had all the money in the world, at least some types of programs. It’s naturally frustrating, then, to be dragged into work that is clearly wrong.
Quite often, programmers have to do things that seem illogical. You learned at uni that good design is important, so why are we ignoring those principles now? Well, sometimes that’s the right thing to do for the business. As an extreme example, let’s say it’s June, 2008, and you have to port a poor-quality, legacy application from four years ago in time for the summer olumpics. Chance are, you’re without a paddle anyway you go, and some agile principles will certainly help, but basically you’re not going to be doing it by the book. Companies have absurd deadlines all the time, and there’s often not much the developers in the trenches can do about that. Again, you can go with the action sometimes mentioned in agile literate, and walk away, but that’s hardly practical and a dubious practice anyway.
My point is that unintuitive practices are often necessary. Dishonest communications make things frustrating because programmers are left wondering why those practices are being adopted. Mature software process involves endowing programmers with at least basic business context, so they can make the right trade-offs. Hand-waving about those things leads to paralysis.
Dishonest communication will not destroy you
Placing head firmly in sand - on some issues at least - is standard behaviour in many parts of many corporations, including many multinationals that have survived for decades - centuries even - and remain profitable to this day. A colleague told me he was once on a finance project which was burning what sounds like a million dollars or more per month, and was obviously doomed. There was a rare opportunity to get an explanation from upper management as to why the sinking ship was continuing to be held afloat. The answer: “It would be impolitic to let it go”. Aahh, so that’s why all those employees, contractors, and consultants are still out there charging you and your shareholders.
Even individual projects survive this type of self-mutlation. Especially when there are enough talented (and probably well-compensated) people around to act as heroes.
The universe is more than IT ...
I think sometimes software professionals are prone to use superlatives, driven by frustration at the strong degree of ignorance about IT that is so prevalent. So we can say things like “this will ruin our chance to compete” or “how on earth will we ever deal with the increase in sales”. ** But somehow, many companies have a way of being resilient to these things and just muddling through them with a combination of manual workarounds, extra staffing, and last-minute duct-taping**. That’s rarely optimal, but it’s usually enough to avert a disaster.
