ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

pinHow Hard Can It Be?

Journal Editorial + Overload Journal #151 - June 2019   Author: Frances Buontempo
Getting different parties to collaborate might sound easy. Frances Buontempo explores where problems and opportunities arise.

We’ve been considering a house move recently, so I’ve been drowning in emails and forms and waiting for the solicitors to keep us up to date with what’s going on. This has distracted me from writing an editorial, as you can imagine. They are sternly refusing to provide any estimates on how long this might take or what they are waiting on. I mean, how hard can it be? OK, to be fair, when we ask a specific question we do get a specific answer, sometimes to a different question. Sometimes, they have even given approximate timelines, saying something like “Searches usually take two weeks.” The estate agents have a different expectation of timelines, warning us this can take much longer. All very confusing and stressful. I’m surprised anyone ever manages to buy a house in the UK. So, as ever, Overload is without an editorial. This did get me thinking though. Managing a project involving programmers or solicitors is like herding cats [Urban dictionary09], as the saying goes.

I can see some parallels between people with different perspectives or motivation trying to collaborate on a project, be that a house-move, writing software, or even a magazine or a book. I find it hard to give estimates for software projects. It is hard. And I don’t always go deep into gory tech details if someone asks what I’m working on at the moment. I try to adapt my response to the person asking. You can talk about APIs to some people or completed features to others. If you’re a team of people working together, it’s even harder to come to an agreement and provide a clear answer to a straight question. Larger teams can make this even harder. I can’t imagine how Kevlin Henney managed to coordinate the 97 Things Every Programmer Should Know book [Henney10] – lots of collaboration!

Instead of talking about people, how do we get code to collaborate? We know collaborate means working together, so can we get different parts code to work together? How hard can it be? It depends. Remote procedure calls (RPCs) give one way to get code to work together. I haven’t used this for a while, but have done my fair share of DCOM and similar. You need to know a lot about the internal workings of the code you call, and can make all sorts of mistakes. But it can work. Another in-tandem approach, without getting as complicated as remote calls, involves trying to get two different languages to work together. You can build several languages into one product using something like Simplified Wrapper and Interface Generator [SWIG] or other bindings, or manually prototype function calls, making sure you find the equivalent of various types, or use a lingua franca, often C. You still need to be very careful about the size and endianness of numbers. Strings are another story. Some shared language and careful testing of assumptions is always required. Alternatively, you can have several ‘products’ or programs, and get them to talk via messages rather than function calls. That seems simpler. In many ways, it is. You do need to spend time agreeing the syntax and semantics messages. How might you deal with different versions of each component? If you need to send new parameter, how do you approach this? I’m getting ahead of myself, though. You can also start thinking about network programming in general and various protocols. Would you like to hear a UDP joke? I would tell you, but you probably won’t get it [Hacker News]. Anyway, one program, in several languages solves some problems. Two or more programs, in the same language, calling each other’s functions is suitable for other situations. Two or more programs communicating via messages give some flexibility, but also needs some thought. Yet another way to get things working together is one program, with several threads. You may have events and delegates, or locks around shared data to orchestrate this. If you are not careful, you can get into trouble. Many interviews immediately ask what a deadlock is when multi-threaded code gets mentioned. I wonder if our solicitors have deadlocked themselves somehow.

Back to collaboration. Orchestration “is the automated configuration, coordination, and management of computer systems and software” according to Wikipedia [Wikipedia-1]. This sounds somewhat like an automated attempt at herding cats. An orchestra plays many instruments together, possibly led by a conductor. The individual players can practise alone, or in smaller groups, but make beautiful music when they come together. This needs some background work and shared language, or at least notation. People can manage to dance together without being coordinated by herds of overseers. If a primary school teacher plays some music, the young people will manage to dance in their own way. They can be individually expressive while moving to the same beat. The idea of timing, through a rhythm or a drum beat is a recurring theme. A rowing team will be guided by a coxswain, in essence counting. It’s the London marathon this Sunday. Some people may practise by trying to keep track of their pace. I suspect there’s a similarity with the pace at which a team works, in order to get a larger project to succeed. Or even some multi-threaded code. How many problems are ‘fixed’ by changing the lengths of sleeps, or other timeouts? Can two people work together if they don’t speak the same language? I dimly recall a program on the television a while ago, exploring how babies through to toddlers learn. One child, who couldn’t yet talk, was encouraged to learn to beat out a drum beat on a table top. He interacted with someone talking to him by responding with various drum beats. Language has a rhythm, and he seemed to instinctively grok that. Little in-roads into getting nearer TCP communication, wherein you get some kind of feedback indicating the message has been received and understood makes some kind of difference.

Let’s expand this out and talk about learning in a programming context. How can you tell if a mentee or apprentice is learning? Chris Oldwood [Oldwood18] suggested counting how many of his jokes the mentee laughed at. Seriously? Damn it. Janet. See what I did there? People who have seen The Rocky Horror Picture Show, tend to immediately say ‘Janet’ after the phrase ‘Damn it’. Sometimes shared ‘secret’ knowledge comes through. This is almost like a beat or tune or, dare I say it, a joke. You are building a common language. If I say ‘Knock, knock’ many people know to respond with ‘Who’s there?’ Is this really communicating? I suspect it would be relatively straightforward to get a chat bot to at least start trying to join in with certain jokes. This puts me in mind of an old children’s game. Has anyone come across Consequences before [Wikipedia-2]? You concertina a piece of paper, and fill out words answering questions one each folder, and refolding so you don’t see what came before by filling in blanks in a story:

Once upon a time, a [name an animal]

went to [name a place]…

and so on.

The stories are then read out and hilarity ensues. A variant involves drawing a person, head, neck, torso, legs, and feet. Then you can just laugh at the pictures afterwards, and not waste time reading a story. Does your software project have consequences? Or at least get developed like Consequences? Do you write code that needs to interface or integrate with other teams’ code? You have probably heard of the Fizz Buzz

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz". [Wiki]

Have you heard of ‘Evil Fizz Buzz’ [codemanship]? This is team work Fizz Buzz, but

  1. Split the team into groups.
  2. Assign each part of FizzBuzz above to a pair. They can only work on code for that part of the whole.
  3. Task them to work together – but only coding/TDD-ing their individual parts – to deliver a complete solution that produces the desired output.
  4. Give them about an hour. And stand back and enjoy the train wreck.

Try it one day. Figuring out how to get groups of people and software to work together can be challenging.

I mentioned chat bots earlier. Let’s talk about the rise of the machines. How can AI and humans collaborate? At the speakers’ dinner at the ACCU conference this year, Echoborg [Echoborg] entertained us. The website proclaims, ‘A funny and thought-provoking show that is created afresh each time by the audience in conversation with an artificial intelligence.’ An actor voices the words of a chat bot. Members of the audience go up and chat to the actor. Speech recognition software sends the words to the chat bot, and the actor speaks back. You had to be there. What happens if two Echoborgs chat? Apparently this happened by mistake once, and was turned off forthwith. Could they collaborate and take over the world? What would they do? A while ago some sensationalist headline hit the world: ‘Facebook shuts down chat bots after they invent their own language.’ The theory is that the bots were tasked with trying to negotiate. The New Scientist said:

One bot was taught to mimic the way people negotiated in English, but it turned out to be a weak negotiator, and too willing to agree to unfavourable terms. A second was tasked with maximising its score. This bot was a much better negotiator but ended up using a nonsensical language impossible for humans to understand. [Reynolds17].

In some ways, negotiation is a form of collaboration, and many industries to end up inventing their own language. Programmers, musicians and solicitors. Just saying!

Asking how to get humans and AI to collaborate possibly has a history that pre-dates computers. Elements of Frankenstein pull on the idea of what happens if people create a ‘living’ autonomous intelligence. That doesn’t end well. I’ve seen a variety of tales about similar goings on. For example, the adventures of a robot trekking across the US, called HitchBOT. One British newspaper, who shall not be named, said “A friendly robot who was hitchhiking its way across America as part of a scientific experiment has been heartlessly attacked and beheaded just 300 miles into its journey.” Informative journalism at its height, not. Wait! Friendly? What would an unfriendly HitchBOT be like? A mash-up of Rutger Hauer in The Hitcher [IMDb-1] and Rutger Hauer in Blade Runner [IMDb-2]?

OK, enough scary dystopian imaginings. How can you have a human in the loop? Many automatic translation programs, in some ways a type of AI to my mind, have relied on humans giving feedback, including better translations. If you have a way to give feedback to a running algorithm (think AI) then you can collaborate. I gave a workshop with Chris Simons at this year’s conference, where we showed how Evolutionary Programming can generate the code for Fizz Buzz. This begs the questions, should you? The code generated was disgusting. But if we then gave feedback, and nudged our fitness functions (think tests) a bit, we might end up with improved code. Maybe code readability doesn’t matter if the machine writes its own code and it does what’s required. No human need ever look at the implementation. People who want code had better be good at writing tests though. Or maybe we do need to learn to collaborate with the machines. ‘Human in the loop’ learning is a trending topic in AI research currently. Watch this space.

OK, so fill in a first sentence:

[..]. How hard can it be?

Go.

Yep, OK, getting the number of dots in an ellipsis correct [Buontempo19]. Collaboration is difficult, frustrating, frequently involves making up languages and communication protocols but can be fun. It needn’t be a collusion or conspiracy, though AI, software engineers and the legal profession can be regarded that way. Teaming up to produce something magical can be amazing. How hard can it be?

References

[Buontempo19] Frances Buontempo (2019) on Twitter, tweeted 27 April 2019: https://twitter.com/fbuontempo/status/1122074050946318341

[codemanship] ‘Evil FizzBuzz’ (or ‘So you think you’re a team?’), 2017, http://codemanship.co.uk/parlezuml/blog/?postid=1494

[Echoborg] http://echoborg.com/

[Hacker News] https://news.ycombinator.com/item?id=8466276

[Henney10] Kevlin Henney (2010) 97 Things Every Programmer Should Know, published by O’Reilly https://www.oreilly.com/library/view/97-things-every/9780596809515/

[IMDb-1] The Hitcher (1986) https://www.imdb.com/title/tt0091209/

[IMDb-2] Blade Runner (1982) https://www.imdb.com/title/tt0083658/

[Oldwood18] Chris Oldwood (2018) ‘Are we nearly there yet?’ Overload 147, Oct 2018, https://accu.org/index.php/journals/2566

[Reynolds17] Matt Reynolds (2017) ‘Chatbots learn how to negotiate and drive a hard bargain’, New Scientist, posted 14 June 2017 at https://www.newscientist.com/article/mg23431304-300-chatbots-learn-how-to-drive-a-hard-bargain/

[SWIG] http://www.swig.org/

[Urbandictionary09] ‘Herding cats’ (definition) at https://www.urbandictionary.com/define.php?term=herding%20cats

[Wiki] http://wiki.c2.com/?FizzBuzzTest

[Wikipedia-1] https://en.wikipedia.org/wiki/Orchestration_(computing)

[Wikipedia-2] https://en.wikipedia.org/wiki/Consequences_(game)

Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD technically in Chemical Engineering, but mainly programming and learning about AI and data mining. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.

Journal Editorial + Overload Journal #151 - June 2019