Torture is bad, everywhere.

In Torture, Plain and Simple, Suzanne points out that while it is true that torture doesn't work, it doesn't matter: it's illegal.  But let's dwell for a minute on the first point: torture doesn't work.

Elaine Scarry gave this subject a scholar's attention in The Body in Pain, where she explained that pain nullifies the world around us -- with extreme pain nothing exists but the pain.  This deconstructs the ego to a point where conversation is meaningless and information extracted in this state has one goal: to make the pain stop.  Say anything to make the pain stop.  In fact, there is a long history of torture being used to extract misinformation to support campaigns of misinformation.

While this simple fact is well established in research, it seems appallingly under communicated.  If it was well communicated, I imagine it would lead to this:

Interrogator 1: Should we do it?

Interrogator 2: Well, it doesn't work.

Interrogator 1: OK then, let's not bother.

The complex ethics simply disappear.



Now this next logical leap may offend some people - minor pains can have a similarly distorting effect.  I am not trying to equate the horrors of torture with unpleasantness, sometimes, of life, but simply pointing out that minor pains similarly distort "reality".  And this has something to do with software.

Be careful what you measure in software development


There is an adage that people do what they are measured on.  This works well when the measures are good and objective.  But in software the measurements are often bad and subjective.  When you measure, you distort -- just ask Heisenberg.  Do your best to measure what you care about as a business (e.g. Customer perception of a product's value) rather than how you make the software (e.g. # of bugs per KLOC).

Be careful asking teams to get it done sooner

We all know about the mythical man month.  But if we all ask ourselves how often we pulled in a date just to have it slip back to its original target (despite this knowledge), we are all guilty of it.  And you can toss features out of the window all you like, you can't always rob the calendar of days or weeks.  Things have their own gestation period -- at some point we need to live with that.

Be careful when you think you know the truth

I consider myself a good listener, which I guarantee is true at least part of the time (such as when I listen).  But when I was involved in a platform release at a previous company, I was certain the team was telling me that we were in good shape on the release.   That is really what I heard.  I was later told that people felt that was the only answer I would accept.  This shocked me, since I was never "that guy."  But unless you sanity check what you are hearing by spending enough time in the hallways and the cubicles and getting a feel for individual's commitment level, you won't really know.  In this case, simply having high expectations and articulating them passionately and consistently began to have a distorting effect -- people began to play into my fiction with a supporting narrative instead of what they really believed to be true.

And so what?

We could listen to Matthew Alexander describe how brains are better than brutality for gathering intelligence, and think about how its lessons apply to the miniature information distortions in our own lives and work.  It comes down to developing real relationships with real people.  In software development, that means a trust relationship with the development team, with sales, with your customers.  Knowing when to push, but knowing when to listen.  And in software, that is often a tough trick to pull off.