Editorial: A little more conversation, a little less action

For almost three years we have had much talk of editorials and reasons for not getting round to actually writing one. This gives the lasting impression that much verbosity and prevarication can stand in the way of actions. The time has probably come to knuckle down and just do it, to coin a phrase. Actions, we are told, speak louder than words. I notice we are told this in words, and not through actions. Why do people say such things? “This calls for immediate discussion,” to borrow another quote [Monty Python].

I was recently called practical – a woman of actions, not words. I was left wondering if that was a veiled insult or not. Or perhaps a way of continuing the discussion thereby avoiding getting stuff done. It is possible it was just an observation and I should be less suspicious. Whether it is appropriate to call someone practical based on what they are saying, rather than seeing them in action is another question. In all fairness, the opposite would presumably be ‘impractical’ and I must say I’m not sure how you could fairly accuse anyone of such a thing. A person in themselves is not impractical as such, but their ideas could be. They may even be ‘inconceivable’, yet as most of us are often reminded, “That word you keep using. I do not think it means what you think it means,” [Inigo Montoya]. The precise details of the accusation of practicality evade me now, but it certainly stemmed from a tension between talking things through to build concord in the group and just starting to get something in place and revisiting it when we all had a bit more knowledge and experience. Some people would prefer to blaze a trail, getting things up and running, fine tuning them afterwards, while others would rather discuss the possible approaches first and wait until everyone is in agreement on the best course of action. A few others will take a dictatorial standpoint and just tell people how they should do things, even going as far as setting up FXCop or other style rules to enforce their point of view, or perhaps inventing a new programming language to enforce code layout [BDFL]. These tensions find parallels in many areas, for example performance versus readability, or even premature optimisation versus deliberate pessimisation [Rule9], where the former finds us trying to make something faster, often via complicated tricks which may not be needed and the latter,

“Is when you write code that is slower than it needs to be, usually by asking for unnecessary extra work, when equivalently complex code would be faster and should just naturally flow out of your fingers.” [GOTW]

I’m not sure I’ve ever seen code flow out of my fingers. Feel free to write in if you have. Of course, we have all seen people argue over the relative merits of either big upfront design or a more incremental approach. How does systems thinking fit into all of this?

If you are starting on a new software project, or even adding features to a legacy code-base, would you get a continuous integration (CI) server up and running straight away, possibly even adding a unit test project, which might well have 0 tests, upfront? Or would you wait until you had explored the code or requirements a little, and added a few tests to see what was possible or appropriate? Or would you allow the team to discuss whether Jenkins or Team City was the best? Or toss a coin to solve that altercation, and then spend weeks arguing about which C++ unit testing framework is the best, eventually hand-rolling your own, without JUnit-style xml output, making it hard to grok the results on your shiny new CI box? Perhaps before any of this you need to spend a few weeks defining ‘Unit test’. Google currently proudly tells me it can find 3,660,000 results (in less than half a second). Good luck with that one. I try to get quick running tests to run on every commit, and might just run a full suite of regression, smoke, hell-fire and brimstone tests in the nightly build. Trying to decide when night is on a distributed team is yet another matter. I wonder if this is what caused me to be called practical? I’ll never know. It would be foolhardy to allow each developer to choose their favoured testing framework, and CI setup and expect them to work together on a project. You could have a couple of rival setups and see which wins, but you many find this time-consuming and there may be no clear winner in the long-run. Let’s face facts – programmers are frequently opinionated and won’t always agree. Even with the previous statement.

Instead of rushing in ‘where angels fear to tread’ [Pope], it might be wise to talk things through as a team first, though be aware that in the previous line Pope does say, “They’ll talk you dead.” Programming is a creative process, needing space and time to flourish. This often comes from bouncing ideas off one another, or sharing experiences, be they war-stories, or tales of a job well done. Be aware that some people do not manage to speak up in a loud group of people for various reasons; strive to include the quieter ones. They may be shy, or perhaps they think you are all wrong and will listen in silence then stay late and do something completely different, unsupervised. Others may be encountering a new approach for the first time, and would rather go away and read around the subject before offering an opinion. Some might want to think things through by trying out a few ideas, maybe via a blog inviting comments from the world and her husband, or by trying a spike project. Others may want to see what a brief internet search turns up, and may even edit the Wikipedia page you were trying to use as evidence while you are arguing. Equally importantly, not everyone means the same things when they say the same words. This project may inspire ‘awe’. It may be ‘interesting’. And not everyone on your team may speak the language you are using as their first language, be that human or programming. Be careful with colloquialisms. Even be aware of whether nodding one’s head means ‘Yes’ or ‘No’. I am told this is not consistent across all cultures. Burkhard Kloss talked about ‘Polyglot programming’ at the conference [Kloss]. In the preview to the ACCU London chapter, he talked about differing human languages and reminded us of the Bible story of the Tower of Babel, emphasising that using different languages can stand in the way of working well together. He then considered how to get various programming languages communicating. The words you use matter and various protocols can help. Don’t speak over people. Say what you mean and mean what you say. Try to find out what others think you mean when they listen to what you say.

It is important to listen as well. We are told, “In space, no-one can hear you scream.” We may also have been asked, “If a tree falls in an empty forest, does it make a sound?” Bishop Berkeley asked a more fundamental question. “If a tree, growing in a quadrangle at a university is not being observed, does it continue to exist?” Esse est percipi – to be, is to be perceived [Berkeley]. As I said, don’t ignore the quieter people on your team. Berkeley himself needs to be understood in the context of Descartes’s dualism and Hobbes’ insistence that only material things exist, perhaps meaning there can be no ideas. Clearly this is completely off-topic, even for an editorial avoidance exercise. Nonetheless, some of Berkeley’s ideas may be pertinent. When studying his writing at University, I was left wondering what people heard and understood when others spoke. When we describe colour, or taste, are we discussing the same experience or do we all have our own world view? If my husband tells me the blue light is flashing on the coffee machine, I may observe it looks orange to me. If the guy beside me at work states that, “All coffee tastes disgusting” while others claim mushrooms are disgusting, does this mean mushrooms are coffee flavoured? Or none of these people have any taste? Even when using the same human language, our experiences and our physiology affect our perceptions. What is blue anyway? Perhaps everyone else is just seeing in shades of grey. Children appear to learn words by repeating what those around them say until they manage to reformulate the sounds into phrases of their own, eventually appearing to be understood. All words are a convention, which can change over time or end up as parallel forks, such as differences between American and British English. Even if you appear to be speaking the same dialect of the same language, communication often seems like a best guess. You need to assume ‘blue’ means the same thing to someone else. Sometimes you need to add extra clarification, as in “That would be a black coffee WITHOUT milk,” or “No, the other left.” Sometimes you seem to be ‘in sync’ with the people you are trying to commune with – you finish each other’s sentences. You grab the keyboard and sort the typos out or refactor the code to something that makes you both nod; hopefully in agreement. This presupposes you are pair programming – some may complain that this is a form of action, not communication. It does suggest they may be more apposite than opposite. It is possible to communicate without words – a band can jam together seemingly spontaneously, without talking it through for hours first. It is possible to express something through mime. Or just pointing and shouting. Or banging your head on the desk.

Looking at the etymology of ‘action’ and ‘conversation’ is revealing. For those who claim they want a little less of the yacky-yack, chatter, natter or to put in more succinctly, in fewer works, talk, and a little more action, don’t forget that an action can also be a lawsuit – a written communication. It also relates to the word ‘deed’, involving legal documents too. With a beautiful symmetry, I notice an etymology website suggests conversation stems from ‘the act of living with’ [Etymonline]. Conversation is something you do, not something you talk about. Acting is putting on a performance, perhaps by reading aloud words someone has written. If we ask for more action and less conversation, or vice versa, the lines are blurred. Sometimes ideas are communicated more effectively by diagrams or precise symbols, say mathematics, or by working on a small code sample together than by vocalising thoughts. Things are not always clear cut. In the end, acting is not enough. There needs to be interaction. This might need to be through some form of conversation. As geeks we might not always do this face to face. An email is ok. Some demo code, or notes on a wiki count. Writing an article can be good. Once in a while, do consider talking to those around you though. Try to listen to others, if you expect them to listen to you. Make an effort to understand their perspective, and try to learn to communicate clearly. If someone really won’t listen, try putting some tests on your CI box and making that email the offender for you when the tests fail. I know I did, and it worked. And always recall the sage advice

“Omit needless words.” [Style]

But don’t take it too far.

“Omit needless words.” [anon]

References

[BDFL] ‘Benevolent dictator for life’ originally used to refer to Guido van Russom, inventor of Python: http://en.wikipedia.org/wiki/Benevolent_dictator_for_life

[Berkeley] http://plato.stanford.edu/entries/berkeley/

[Etymonline] http://www.etymonline.com/index.php?term=conversation

[GOTW] http://herbsutter.com/2013/05/13/gotw-2-solution-temporary-objects/

[Inigo Montoya] The Princess Bride http://www.imdb.com/title/tt0093779/quotes

[Kloss] ‘Thriving in a polyglot world.’ ACCU2015 http://accu.org/index.php/conferences/accu_conference_2015/accu2015_sessions#thriving_in_a_polyglot_world

[Monty Python] The Life of Brian http://montypython.50webs.com/scripts/Life_of_Brian/23.htm

[Pope] Alexander Pope An essay on criticism, 1709.

[Rule9] C++ Coding Standards Sutter and Alexandrescu. 2004.

[Style] The Elements of Style Strunk. 1918.