Using humour to make software development more enjoyable

Software engineering mainly deals with technical problems, but the solutions to these problems are often found in a collaborative manner, which requires care and engagement from developers. Organisations use various strategies to engage developers. For example, the OpenBSD project celebrates each major release with a song, while Ubuntu, Fedora, and Debian celebrate major milestones by organising release parties. Meanwhile, companies like Apple and Google are known to add a touch of humour to their product demos.

The authors of this week’s paper argue that humour can also be a good way to engage developers. They do this by first discussing three examples of humour in open source software:

• Test inputs for automated test cases are often handcrafted manually, which can be challenging and time-consuming.

  faker is a Ruby library that can be used to dynamically generate test inputs. Typical examples include input types like customer contact details and barcodes, but faker also includes the ability to generate humorous texts (e.g. funny names like “Ben Thair” and “Don Thatt” or cultural references to TV shows like Seinfeld).

  Why does faker include humorous generators? According to a core maintainer of the faker project, this was done because humour makes programmers happy. But the repository’s GitHub activity also suggests that humour works well to attract new contributions from people who wish to add their favourite TV show.

• lolcommits is another prominent example of a humorous software development tool. This command-line utility installs a post-commit hook that triggers lolcommits to capture an image using the device’s camera and overlay it with the commit’s hash and message in a meme-like fashion. Captured images may show a wide range of emotions, from frustration to excitement. Some developers even pose for photos with their teammates!

  A thriving community has emerged around lolcommits, with people making video montages of lolcommits over the years, and referencing lolcommits on their blogs and socials.

• Volkswagen made headlines in 2015, when it was discovered that they had engineered their vehicles to emit fewer environmentally harmful pollutants, but only when the vehicles detected that they were being tested in a laboratory.

  The volkswagen tool similarly tricks a test suite into believing that all tests pass when it is being run in a continuous integration (CI) pipeline. Although this doesn’t serve any useful purpose by itself (aside from being funny), it has led to the development of another tool that is useful: is-ci, which can be used to perform certain actions that are only needed (or skipped) in CI environments.

To learn more about the role of humour in software development, an online survey was conducted among 125 participants. Virtually all participants were developers, with varying levels of experience across various domains.

When asked what participants believed to be appropriate places for humour, most answered that comments and documentation are the best locations to incorporate humour. Next come test inputs, followed by log messages and names of identifiers like variable, class, and functions (side note: The et.phone_home function in the Erlang standard library is a good example of this type of humour.).

The survey also highlights several reasons for incorporating humour within software development. One obvious reason is that humour in code helps keep it fun. But humour has other benefits too. For instance, humour is believed to promote a sense of community, as it makes developers feel more connected to their past and current colleagues. Moreover, humour in places like tests can facilitate a common understanding of what is being tested.

Not all participants make use of humour in their software. Some believe that incorporating humour within software may be detrimental to its quality, as it may reduce readability and knowledge transfer. Others take a more nuanced approach and recommend exercising caution when practising it, for instance by considering its impact on performance and quality – humorous code should never be exposed to the end user, and no jokes simply for the sake of jokes! Finally, humour should not be offensive (side note: This is reportedly quite challenging for contributions to faker’s south_park generator.) or hinder respectful collaboration.