Pair programming, code reviews and checking in cheatsheet, part one.

My software development cheatsheet, part 1

Pair Programming
Pair programming is a technique that hopes to achieve three main things. Those being: better architectural design, shared knowledge and code quality. Pair programming often reduces waste during code reviews as core concepts are already decided, leading to fewer rewrites.  When done well it helps to build trust and understanding between developers. The following steps are all equally important and can be considered a cheat sheet.

• Define the task, with small goals in mind. You’ll then be able to move in the same direction quickly.
• Agree on the solution. It’s worth spending a little time before coding to fix in your minds how your solution will work.
• Talk constantly about what you are both doing. 
• The developer with the keyboard writes, while the other one directs. An analogy is that of driver and a navigator. The driver at the keyboard makes the tactical decisions while the navigator keeps them on course and suggests short cuts. 
• Switch roles at least every two hours and maybe even every 45 minutes.
• Consider checking into a temporary pair-programming local branch in git at each swap point. This shouldn’t be master.

Code Reviews
Code reviews are there to catch mistakes, keep the code base balanced and gain the insight of another pair of eyes before you submit your work to the wider business. It’s there to help and protect you, not to criticise you or force you to change complete direction. When you are reviewing others code, you should be wary of asking for changes to make the code look like you had written it. The following points should be considered during code review.

• Select a reviewer as close to the code as possible. Therefore if you are pair programming or working with someone on a user story, they should be the reviewer. You must stick with this reviewer for re-reviews.
• If at all possible, do code review together at a desk before it is even pushed to Git. Even better correct problems there and then. This makes it more immediate, less confrontational, more productive and a better experience all round.
• Review the code, not the coder. Refer to the code, not the coder.  Don’t say ‘your code here tests the wrong object’ but ‘this code tests wrongObject, not rightObject’
• The reviewer should assume that things have been done by the reviewee for good reason. The developer has likely given it more thought than the reviewer, so challenges to how something has been done should be diplomatic and open. Equally, the developer may not have thought of everything and may not have thought of the best solution. When such things are raised in review, they should be discussed and either corrected or clarified (e.g. better code structure or comments may resolve the issue).
• The developer should not take feedback as personal criticism. They should view them as honest questions/feedback aimed at ensuring that the delivered code is of an acceptable quality (fulfils the requirement, complies with best practice in terms of architecture, design and code etc.). Any feedback should be considered openly and as an opportunity for improvement, learning and to deliver a better end product.
• Be clear in identifying the issue and suggest obvious fixes. ‘This doesn’t work’ is worse than useless. 
• Programming style should be challenged not demanded. Rather than saying ‘This code style is not following the command pattern’ say ‘Consider the use of the command pattern?’ This however is not an excuse to ignore best practice or consistency issues with the code by the developer.
• When you review code you become part of that story. If a reviewer just rubber stamp the review, they’re directly responsible for failure. If they sit on a review, or re-review you are responsible for it being held up. Check you requested reviews often.
• Always respond to every code review comment. Either with “Done” or with a suitable response. This aids re-review.
• Point out the good. When reviewing code you may learn things yourself or spot elegant solutions. When that happens, say so, the coder may be unsure that it was elegant and it positively reinforces the good stuff.

Checking in
Git is complex and powerful, and there is a lot to say on it, however these general check-in points are important.

• The code you write is valuable and needs to be backed up as much as possible so that there is no danger of losing it.
• Check the code in at end of the day, as a minimum. Otherwise you are preventing others from picking up the work to get it finished. We can’t ever predict what will happen from one day to the next in terms of illness or transport problems.
• More frequent commits mean more flexibility in code reviews. This leads to faster turnaround and less context switching.  Small commits are easier to understand, easier to review, and can be merged to master much sooner. This means that your code gets picked up by others sooner, reducing the complexity of conflict resolution, and ensuring that your code is in use sooner which gives you a higher degree of confidence that there are no corner cases that you missed in your unit testing.

Everything I know about agile software development I learnt from playing Dungeons & Dragons

Wikipedia src : Sargoth

Roleplaying games, the kind you play using odd shaped dice sat around a table with friends, are about three things. You play a role, usually a dramatic heroine or hero, you are part of a story and you overcome challenges together achieve some goal. Software development is also best done sat in groups, with people you like. It’s also about overcoming challenges to achieve a group goal, and often each person in the team has a particular role to play.

Diversity
The most famous RPG is Dungeons and Dragon, in which a party of adventurers explore Tolkienesque worlds fighting foes and finding treasure. The secret to a successful adventuring party is diversity and the same is true for development teams. If everyone in your team has the same background, the same experiences and outlook they’ll tend to solve problems in singular way and make software for people like themselves. An adventuring party made of just dwarven warriors might find it easy to fight their way through hordes of orcs, but without a cunning thief who will pick the lock to the impenetrable doors that guard the dragon’s treasure? Better to have a diverse team and end up with software that has been thought through by people of different backgrounds, genders and cultures, teams who won’t get snagged by issues that come from a single perspective.

Leading
Roleplaying games require a Game Master, sometimes called a Dungeon Master. This is the person who has the story their head, who frames the challenges and who plays the parts of the other characters in the story. It’s like a Scrum Master and Product Owner in one. The worst kind of Dungeon Master is one who ‘railroads’ the players. Rather than encouraging the players to figure out how to proceed, they tell the players what to do and railroad them into a particular course of action. This isn’t much fun for the players and rarely goes to plan as the Dungeon Master can’t think of every turn beforehand. It’s not playing to the strength of the game. The same is true for software development. When you’ve hired a talented group of developers, testers, product owners and sys ops don’t tell them as a manager what to do. Tell them what is required, and let them get there themselves. If they wander off from the user story, guide them back to it by reminding them of the features needed.

Resource planning
A big part of roleplaying is essentially resource management. Players worry about how many spells they can cast, how many gold coins it costs to buy that magic axe or how many sips they have left in their potion of healing. Eventually it becomes risk management. Trolls have hidden enough gold to buy the magic axe and a bunch of healing potions, but the fight might be so tough that characters could be defeated. Perhaps it’s better to face the orcs first and use the little treasure they have to buy a single healing potion so that they have a better chance of defeating the trolls. Or maybe they should try and sneak in and steal the treasure instead.

Software team’s dilemma is how to divide the work up between them. It’s rare that there are enough programmers, let alone QA to work on all the ideas the company has at once. It helps to think of resource planning in terms of risk management. Is it possible to take a small step that brings in some value rather than rushing into a big long project without knowing it’ll be successful? This of course is a fundamental principle in Agile software development, but incremental gains work just as well in D&D as it does in product development. When you don’t have quite enough QA engineers to give you complete coverage, do you risk reducing coverage or match the pace of development with that of testing? It depends on how valuable and risky the project is. Orcs or Trolls? Silver pieces or gold?

Experience
As characters gain in experience in roleplaying games they also gain in power, and more interestingly options. A freshly made wizard can recite a single and low powered spell once per day but as they gain in experience, and go up in levels their titles and options change. An experienced Enchanter can change shape, go invisible, befriend monsters, throw fireballs. They can also build magical towers that aid their spells and train apprentices to do their lesser magic.

The same is true in a way of developers, both in terms of technical and product experience. When they start out they are often given very specific jobs to do that aren’t very complex. As time goes on they learn more about best practice and the way their software is used. The variety of problems they can solve increases, but additionally and vitally the creativity they can bring to bear on product development also improves. Senior team members should be building wizard’s towers and training apprentices.   

No More Heroes
There is one area where software development shouldn’t be like RPGs. In Dungeons and Dragons the heros and heroines grow in power and become superheroes, saviours, invincible and invaluable.

When you have heroes in a software development team it can cause all manner of problems. These are the people who stay late, who can seemingly solve any problem, who will avoid all the process and management layers to get things done. The trouble is they never look back, they rarely leave behind code that others can work with in their quest to get things done and disrupt the workflow of others because of their sudden needs for unplanned QA or releases. The set expectations that others can’t meet, hoard knowledge and avoid helping others. While the hero mentality is noble, and not to be squandered, it is better to show them why teamwork is finally more productive and desirable that wearing spandex and a mask.