Posted by n.chuehong on 28 October 2013 - 3:58pm

By Neil Chue Hong, Director.

On 26 October, I headed to the amazing Ravensbourne media and design campus in North Greenwich with Aleksandra Pawlik for MozFest13. MozFest is a huge unconference held by the Mozilla Foundation that brings together thinkers, makers, learners, and designers. This year, following the creation of the Mozilla Science Lab (whose first project is Software Carpentry) we ran our popular What Makes Good Code Good session in the MozFest Science track.

We've previously run these discussions in rooms full of ecologists, digital social researchers, software developers and researchers in the north-east of the UK. I was interested in whether the outcomes would vary given the potentially very different, diverse audience. There was also some trepidation as this was the first time that I was leading the session (previously run by my amazing colleague Mike Jackson), and I had no idea whether 5, 50 or 500 people would turn up! As it was, the 25 people who participated put up with me asking them to move around the room into different groups to consider the questions of what they considered indicators of good code, what blockers mean it's difficult to produce good code, and what solutions there might be to address these.

There was quite a mix of people, including scientists, commercial developers, and even a few non-coders! First we split the groups up into scientists, developers (for science, and non-science), and those who were somewhere in-between. After discussions in the groups and prioritisation, the attendees proposed that good code should be:

• Simple: so it's easy to understand
• Readable: with semantics and a style guide
• Open Source: which makes it easy to develop further and extend
• Documented: so that it's still understandable after a period of time
• Correct: so it does what it's supposed to do
• Efficient: so you don't waste time or resources
• Unit tests: because you wouldn't not calibrate a scale before using it
• Structured: because it makes code more readable
• Preserved: so that a record of it remains
• Portable: so it doesn't just run on my current machine
• Well designed: so it's easier to adapt to different systems
• Follows best practices of the community: because this helps promote good practice

The scientists focussed on simplicity, portability and code that was easy to understand. The developers prioritised design, efficiency and correctness. Both groups highly rated openness, which chimes in well with the Mozilla Foundation's principles. Other ideas of what made good code included: accurate APIs, good organisation of files and folders, reasonable size functions with a singular purpose, evidence of adoption (e.g. stars on GitHub), stable dependencies, modular, maintained, software stack well described and archived, high cohesion, and loose coupling. These overlapped closely with other definitions of good code as expressed in numerous articles and blogs as well as the responses from other workshops. There was some amusement that no one had suggested "uses a source code repository for version control" though this requirement was taken as a given by the audience.

We then split the groups up again, clustering them by whether they worked in industry or academia. After discussing lots of issues and barriers, the participants settled on the following top blockers:

• Lack of time: if you don't have time to do it badly, you don't have time to do it well
• Lack of incentive/motivation: why waste your time on things which aren't rewarded?
• Making assumptions about input and what you'll remember: meaning that decisions get lost
• Lack of organisation/communication/process: for anything that requires cooperation
• Gatekeeping / bus factor: isolation of knowledge and control
• Technical debt: too much code that must be continued
• Lack of money
• Bad tools / IDEs
• Lack of knowledge / experience
• Lack of culture of good code / software quality
• Non-convergent objectives

Amusingly, three of the four groups had put down laziness as a blocker, though no one considered it as one of their top three!

Next we asked everyone to come up with solutions to overcome the blockers. I thought I was quite generous, giving people a budget of $1 billion for their ideas, and 25 years to enact them. In return, the group came up with some amazing ideas:

• Teach 12 year olds how to code well, and wait for them to grow up: catch them early
• Get coding courses on the curriculum: keep teaching them as there are more distractions as you grow
• Encourage market mechanisms that support the most important scientific software: give researchers credits that they can invest in further development of software that they choose
• Align grant funding towards software development + tap into EU policy
• Use continuous integration: get them embedded in IDEs
• Agile/scrum methodologies: make sure people don't pick up bad practices
• Statistics to find outliers

In particular the first three ideas are ones which we will hope to take forward in partnership with other organisations in different ways - the future researcher will be software savvy!

Finally, we asked everyone for one thing they'd learnt that they would share outside the room:

• That people are generally in agreement about good code
• The importance of education
• The need for increased communication to solve problems as they have often been encountered before
• Awareness of the necessity of having good programming in science
• Stress great importance of readability
• The problem of technical debt is almost unsolvable
• Stop being lazy when you're coding and everyone will be happy
• Talk about taking more time when you code and think about your code before you start writing it
• Clarity in your work so that others can verify what you have done
• That we have connections to do something about this

As for me, I learned how similar the challenges in science are to other Mozilla Foundation tracks, particularly Open Journalism, I met FireFox, rode a cable car just before the impending St Judes storm and remixed my first HTML5 mobile game app. I'll definitely be coming back again!

A big thank you to Kaitlin Thaney for programming our session, the MozFest13 organisers for putting on a great conference, and all the participants for taking part and sharing their time, experiences and opinions. You can read all the raw ideas and download the materials if you want to run a session yourself - if you do, let us know what you think makes good code good!