Gone are the days of ‘traditional’ programming practices, where teams of software developers might have restricted their communciation to once weekly meetings and worked towards yearly release dates; we are now accustomed to a far more iterative process: daily standups, TDD and continuous integration and/or deployment. This iterative process is of course part of the wider set of agile programming practices.
At Lambert Labs we take our agile programming practices seriously. As part of this we regularly use pair programming as a way to ensure that we are working efficiently and effectively as possible.
Pair Programming Workstation Setup
The workstation setup for pair programming is important. If two developers are around one workstation for significant periods of time, they might get uncomfortable. This is why we use ‘dual workstations’ for our pair programming. Our dual workstations are made up of two desks and four monitors, but only one computer – the two monitors on the desk with the computer are duplicated to the two monitors on the desk without the computer. This means that both developers can sit in comfort while pair programming!
Code exposure: pair programming helps developers of all levels of seniority get exposure to different parts of the codebase. This is really important because it helps developers understand the overall system that they are working on and also helps provide continuity when a developer with ownership of a section of the codebase is on holiday or otherwise engaged.
Code quality: if two developers are looking at the same piece of code during development then this is similar to having an extremely thorough review process (think how often a reviewer spends as long reviewing code as the developer spent writing it – very rarely!).
Focus: yes, pair programmers might have a chat and a giggle, but what they won’t do is things like check social media, check their emails and surf the net. In this case, working together brings more productivity.
Morale: working together is fun, and it boosts morale! The life of a developer can at times be unneccesarily quiet. Pair programming discourages deathly silences and encourages collaboration.
Fewer bugs: working as a pair means that fewer bugs creep into the code base. This reduces time spent debugging at a later stage.
Lack of ownership: developers don’t always feel that they have ownership of a section of the codebase, and feel as though they are getting pulled in multiple directions.
Lack of synergy: if two developers don’t ‘click’ when they are working together then the relationship might not be productive – in some cases this is just human nature!
At Lambert Labs we find that the benefits of pair programming hugely outweigh the drawbacks. It improves our productivity and standards, and we will stick with it moving forwards 🙂
At Lambert Labs we work with a range of clients across different sectors. What can be awkward is that they often use completely different DevOps and project management tools. On the DevOps side, some clients use AWS while others prefer Google Cloud Platform or even PaaS providers such as Heroku. Some clients use CircleCI while others prefer to use Travis/Jenkins. From the project management perspective Jira and Confluence are very popular, but a selection of our smaller projects still make use of Trello.
As a software development agency it is important for us to be expert users of as many of these project management tools as possible because it enables us to work on a broader range of projects. We recently started working on a project with a client that uses GitHub for code hosting and Jira for issue tracking. Integrating Jira with GitHub makes it easier for our project managers and software engineers to keep track of the GitHub branches and pull requests that correspond to tickets in Jira. The benefits of integration are shown in the example Jira ticket below, where there are links to a GitHub branch and pull request in the development section (these appear automatically as part of the integration).
- A Jira account with administration rights
- A personal GitHub account, or a GitHub organisation account with administration rights
Setting up GitHub
First, navigate to your GitHub account settings page (if you navigate to your personal settings, this will eventually give Jira access to your personal repositories. If you navigate to your organisation settings, this will eventually give Jira access to your organisation’s repositories). Go to ‘Developer Settings -> OAuth Apps -> New OAuth App’. You will be presented with the following page:
Fill in the following details and click on ‘Register Application’:
- Application Name: Jira
- Homepage URL: https://yoursubdomain.atlassian.net/
- Application Description: Jira integration
- Authorization Callback URL: https://yoursubdomain.atlassian.net/
After clicking on ‘Register Application’ you will be taken through to a confirmation page giving you a Client ID an Client Secret. Make a note of these – you will need them in a moment.
Setting up Jira
Now navigate to your organisation’s dashboard on Jira and go to ‘Settings -> Applications -> DVCS Accounts -> ‘Link GitHub Account’. You will be prompted with the following popup:
Choose either GitHub or Github Enterprise as your host (depending on what is appropriate) and put either your GitHub username or GitHub organisation name as the ‘Team or User Account’ (again, depending on what is appropriate). Client ID and Client Secret should be self explanatory! After you click ‘Add’ you will be prompted by an authorisation page (you should authorise the app, and may be required to enter your password as part of this process). You will then be redirected to the DVCS accounts page in Jira, where you should now see your linked GitHub account.
The last step is to understand how to make sure your GitHub branches and pull requests appear in the corresponding Jira tickets. To ensure the link takes place, you must name your Git(Hub) branches as ‘<JiraProjectKey>-<Jira-Issue-Number>-normal-git-branch-name’. You can find your Jira Project Key (on a per project basis) by going to a Jira project and navigating to settings. You will see a details page similar to the following:
So, for the above Jira project, an example branch name would be ‘LMS-5-my-new-feature’. As soon as you follow this naming convention for your branches you will see branches and pull requests appearing in your Jira tickets. Nice!