This is an expansion of a talk I gave at Geek Girl Dinners Sydney titled “Happy Programmers for Happy Code”. I’ve written down some of my notes and things I said during the talk.

Talk Abstract

Programmers want to be able to write code, and write it quickly and write it efficiently. To do this, we need appropriate tools and infrastructure in place. In this talk I will outline some of the tools every programming shop should have: version control, build system, wiki, bug tracking system, nightly builds and testing framework. I’ll also talk about the importance of testing, different types of test, and how to incorporate tests into your codebase and build system. Finally I’ll open the floor for a group discussion about what tools have helped you and your organisation

The slides for the talk can be downloaded here: attachment:happyhackers.pdf

What is happy code?

Correct

As correct as humanely possible. It’s probably too hard to use formal methods to determine correctness, but it should at least be tested, and not obviously wrong.

Understandable

• well documented (internally & externally)
• Gotchyas highlighted “HERE BE DRAGONS”
• well defined APIs between components - no monolithic bowl of spaghetti!
• straight forward: as simple as it can be, but no simpler
• No onion code

Efficient

Might be correct, and easy to comprehend, but it’s no good if it takes the life of the universe to run.

Testable

• So you can determine whether it’s correct and efficient.
• So you can quickly find out if you’ve broken anything when fixing a bug or adding a feature

Supportable

Most of the work done on code is in a ‘support’ phase. Writing codes doesn’t take very long, but maintaining takes a lot of time and effort.

• Means if someone else (or you in 3 months time) wants to fix a bug or add a feature to the code, they have an easy job of doing so.
• They can understand the code
• They can easily test their changes
• They can easily modify your code

What are Happy Programmers?

Other than interesting problems to solve, they have:

Good Tools

So they can do their job without being distracted by infrastructure issues.

Good Policies

Such as policies for:

• committing code
• reviewing code
• testing code
• coding style

Good Colleagues!

Bad colleagues can make you miserable!

Happy Code!

It’s recursive!

The right tools

• Version Control
• Knowledge Management System
• Bug/Ticket/Task tracking system
• Build System
• Testing System
• Development tools

Version Control

Comes in two main flavours:

• Centralised (CVS, SVN)
• Distributed (Darcs, Mercurial, git)

Use your favourite search engine to find a comprehensive comparison of different systems

What a Version Control System Needs to provide

• Dealing with Conflicts: “My current team has a bizarre fear of concurrent edits. Apparently they used some sort of lame source control software in the past that let multiple people edit a file, and whoever checked in last won!” -Kathryn from #linuxchix
• Managing trees (branches, tags)
• Porting bug-fixes to different versions (cherry-picking changes)

Knowledge Management Systems

You don’t want all your companies knowledge to exist as conversations between cubicles or emails in people’s inboxes..

• Any is better than none
• Wikis, Content Management Systems (CMS), Document management systems (Sharepoint), combined solutions (fogBugz, Jira)
• Should be searchable and organisable

What goes into a KMS?

• Specification
• Important decisions
• Design documents
• Information about target platforms
• Essential information for employees

Task Tracking System

• Lets you manage Bugs, Tasks and Tickets
• Integration with Version Control System is useful. Means you can flag changesets with related bug numbers (or vice-versa) so that if someone is looking at the code, they know why it’s been changed the way it has.

• Helps with project management - happy managers for happy programmers
• Often bundled with VCS, wiki or both.

Build System

• Ideally a one-step build process
• Easy building for multiple different targets (if relevant) - so that you can build for that embedded ARM box as easily as you can build for x86.
• Integration with test system and version control system - so you can run nightly builds and tests without human intervention.

Testing

• Ideally should be in place before you start coding - retrofitting testing on a system that hasn’t been designed for it is like having your teeth pulled.
• “Continuous Integration” - so that you don’t have to stay at work until 2am trying to integrate what everyone has worked on the night before your ship date.
• Nightly builds/Nightly tests - so you can nip problems at the bud. You find out what’s broken straight away. If someone forgets to run the tests before committing, they find out soon. You can run things like lint on the code to flag potential errors not caught by the compiler or the tests.
• Staging system - so you don’t find out about dependencies after you ship!

Types of Testing

• “Does it work?” testing - run it, and see it doesn’t crash straight away
• Unit testing
• Regression testing
• Performance testing
• User Acceptance Testing (UAT)

Development Tools

What tools?

• The right language for the job - the wrong one will make your life difficult. Unfortunately most people don’t have a choice in what language they program in.
• IDEs - love them or hate them.
• Profilers, debuggers, monitoring tools
• Network debugging tools

You should know how to use your tools very well (so you think about the problem, not how to use the tool!), be familiar with all useful featuers in your IDE, editor, OS.. etc.

Ask others about tools that might make your job easier, you’ll often be pleasently surprised!

What tools do you find indispensable? (audience question)

• Vim
• Maven
• Wireshark
• The Atlassian people all suggested Atlassian tools! (check them out on their webpage)
• The ThoughtWorks people suggested ThoughtWorks tools! (check them out on their webpage)
• CScope/Exuberant ctags
• Valgrind
• Electric Fence
• kcachegrind
• Emacs

(there were quite a few others which I don’t remember, email me with them).