Here is a kind of step-by-step guide to doing pair programming. If your team doesn’t adopt any other principles of XP or lean, this is the one thing that will give the greatest benefit for adoption. This is a good recipe for ROI++.

 

Attitudes

In my experience, programmers are the least willing of all professionals in the software development industry to be paired up on tasks. For some reason, we developers seem to have attitudes and fears about this mode of work. I have heard attitudes expressed like "I don't want someone to be nitpicking every character I type," "I dont want to share my keyboard." There are also un-spoken fears that I have heard told: "They might find out that I'm not as smart as they think I am," "the other guy might make me look stupid," and "I don't want them to know how I really write code." These attitudes and fears are the number one barrier to doing pair programming.

 

C4 Requirements Checklist

For people to be able to do pair programming, I suggest the following readiness checklist to determine if someone is ready. Not everyone is at a point where pairing makes sense for them. When creating a team to do pairing, it is important that everyone have an open mind to trying the process. Give the list to the people and let them do it on their own, and decide for themselves. Don't collect their lists, just their yes or no answer.

 

1. Am I willing to Cooperate – do I really want to do this or is someone just telling me I have to do it? Am I bought-in to the idea or is it being forced on me?
2. Am I willing to Collaborate – can I work together with others in a team environment where we all pitch in together to accomplish a task, or do I need to do things only by myself to be successful?
3. Am I willing to Communicate – can I tell my team mates what I am thinking? Can I get a point across verbally? Can I take a spontaneous thought and talk it through verbally and get someone else to understand me? Am I willing to work toward these goals if I’m not quite there yet?
4. Am I willing to Create – can I be of a mind-set that I am creating something of value regardless of the process, and am I willing to try something new to accomplish this?

 

Implementing It

If your team is on-board with the C4 checklist, congratulations! You now are able to start off on a wonderful process of building some great software. My suggestion now is to get some resources together. Here’s a starting recommendation.

 

1. Pair Working Space

1. The team should ideally have a smallish space to do their pair programming work. This should be separate from offices or cubicles. While this is not always possible, I have seen some great creativity used to put the team together in their own space. Sometimes this means just adopting a round meeting table in the middle of a cube farm. Whatever it means for your team, do establish the pair working space. Use the guideline of 6-8 square feet per person, and keep the team size under 10.
1. Desks, chairs
1. One desk for every two people, and one chair per person, with one extra chair is just about perfect. Don’t have the desks more than a few feet apart. Keep the team together in a smallish space. This will greatly aid cross-communication between pairs while development is happening.
2. Machines
1. One development machine per desk. Two team members will be sharing one machine.
3. Monitors, Keyboards, Mice
1. Two of each per desk. Space them two feet apart so that people can have a little personal space. Connect both monitors to the dual-head video card, and clone the display so both have the same image. Use USB keyboards and mice, and place one each in front of each monitor.

 

Orienting the Team to Pairing

Be sure to orient your team to this kind of thing first. Let them know that they will be expected to work together on one machine sharing control, but that each will have their own keyboard, monitor, and mouse. Remind them that cooperation and verbal communication is essential when working with a partner.

 

Hours and Etiquette

When working closely with other people in this way, we need to be polite, focused, and productive. There are times for all of us when we just aren’t all three of these, and that’s OK – it’s just human nature. We need to be able to “check out” and go elsewhere if that’s the case for anyone at a given time. [Assuming a standard 8AM-5PM day…] Start pairing at 10am, take lunch at noon, and stop by 3PM. This gives everyone some time to work on other things or take meetings outside of pairing. Adjust times accordingly for your team, but this is a good starting point. Don’t make the mistake of thinking your team can pair for 8 hours a day. A 5 or 6 hour pairing day is a lot, even for an experienced team.

 

Challenges

At first, there may be personality challenges. Some people are more easily able to communicate and share control. Don’t worry if the first few days are a bit rocky, this actually can be a good learning experience (as long as nobody blows up). Keep an eye on tempers to make sure that hot situations can be defused before they cause problems. One technique that works well is to switch pairing partners at the middle of the day, or at least every day. This gets people new learning experiences and moves knowledge around the team (another great benefit).

 

There is one specific challenge that I want to bring up, because on a pairing team it can be a real issue. Everyone should wash their hands. A lot. We shouldn’t have to remind people to wash after visiting the bathroom, but DO it anyway. I encourage and ask people to use hand sanitizer before touching the keyboard at my workstation. Bugs have really gotten nasty out there, if you haven’t noticed. If there is an illness, be sure to make the people stay at home, or a single cold or flu can wipe out all development pretty fast. I recommend spending $2 for a small bottle of hand sanitizer for every workstation and placing it in plain sight.

 

Benefits

• Team knowledge share
1. Knowledge will naturally migrate through the team, since people working together will share knowledge about a task. Rotating people through tasks is a fantastic way to raise product knowledge and awareness for a low cost.
• Better code
1. Two pair of eyes on a piece of code are always better than one pair. We sometimes call this process “real-time code review.” Mistakes are simply caught far, far sooner. Code mistakes and poor design decisions simply just evaporate as two people think about the code as it’s being written.
• Quicker code
1. Not that it executes faster, but it probably will do that too. A pair can produce a solution to a feature request far faster than a single developer in almost all cases I have seen, and every study I have ever read. It’s not half the time, but it’s probably more like 2/3 (a 33% speed improvement for you percentage folks…)
• Tight-knit team
1. The team will be more integrated, stick together, be more cohesive, and more social together. People on a pairing team will be united for the delivery of a product, and it the experience will form bonds between team members.
• High-performance team
1. Pair programming teams will almost always outperform teams that don’t use this technique. The more experience teams get to have with pairing will yield even higher performance results.
• Higher morale
1. Teams that use pair programming are almost always happier, and more positive about their working experience.

Summary

When we find the people who have an open mind, and are committed to success as a team, we have a great asset to leverage to write good software. Using the technique of pair programming in a shared workspace, we have many benefits for all - the company, the team, and most importantly, the customer. It takes a little work to get to a high-performance team, but it really isn’t much, and in my opinion, easier than finding a way to coax performance from a non-paired team.

 

If you have any input or feedback on this article, I welcome it – please post a comment below.

"Obviously, Development should be responsible for the acceptance tests. The developers are the ones on the team who are the best at writing good code. The developers are best able to turn the acceptance criteria into valid executable specifications. Development then can use the automated acceptance tests to drive the development TDD cycle."

"In QA, we never totally trust the developers. We do trust them to do the right thing. However, we have a saying in QA - Trust but Verify. QA should be responsible for the acceptance tests. At the end of the day, it is our job to make sure that the software meets the criteria for acceptance, so it's really a QA ballpark. Dev's should focus on unit tests."

Two strong opinions, and really I think both are right. Development should be using acceptance tests to drive an ATDD cycle. Developers are (usually) better at writing code than SDETs, so they do a more efficient job on acceptance tests. But QA probably has a more even overall view of the software, and from a different and more independent perspective, so they should be writing the acceptance tests as well as the other test automation. QA also has the responsibility of signing off on the code, so they should be writing the acceptance tests.

So, this may be one way to resolve the issue. Have developers and testers both work on automated acceptance tests for the first story. When the tests are completed, developers are free to begin working on the unit tests and code to satisfy the acceptance tests. QA can then begin test case generation and automation implementation.

I believe that this solution is the best of both worlds, because Development and QA will be completely in sync and on the same page for all of the stories where the acceptance tests are co-developed. There won't be any ambiguity on whether the software meets criteria, and both teams will be in agreement as to what is passing and what isn't. The tests will be well-written, and they will run as efficiently and accurately as possible. They will be written with multiple perspectives - the customer (who supplied the acceptance criteria), QA who makes sure that the test accurately guarantees the outcome, and Development, who makes automation quicker to implement and more efficient.

With automated acceptance tests co-written by dev and test, we have a great common point of communication, and a good example of how teamwork can really help software shine and inspire confidence and trust in the eye of the customer.

The UW Extension for Professional Development and Continuing Education now has a Certificate Program in Agile Development. It's being taught by some guys I used to work with first-hand, so I happen to know they are all pretty good at Agile Development. They are certainly highly qualified, and this certification course is a good opportunity for those folks who may not be as familiar with Agile principles to get some good instruction on how to do it well. Be sure to apply now, as this course is likely to fill fast.

I have heard a lot of discussion lately about the use of the "#region" directive in C#. There are various camps (some religious) on this topic, so let me throw in my twopence.

Many developers like to use regions to collapse sections of the code because it makes it easier for them to focus on a particular section. That's nice.

If there is that much code in a single file (which *should* be only ONE class), then there is probably too much code in that class. Class design should be focused on one specific thing. According to good OO principles, classes should be autonomous, and do one specific thing. Classes should be intelligent groupings for functionality relating to a specific, focused purpose. The use of the region to group code bits together in a file is a good indication that there is probably too much code.

Simplicity is a highly desired principle in software development. It's the simplest thing that gets the kudos, not the most complicated. Developers who try to write complex, convoluted code so that they can look good to their peers are really doing the opposite. Added complexity is very costly, in time for other people to understand it, debug it, and maintain it.

Here are some ways to determine some code smells in this area.

• Do methods have more than 25 lines of code? If so they are probably too big - this is a code smell.
• Do classes have more than 12 methods? If so, this may be another code smell. Classes that have lots of methods probably are doing too much. See if they can be broken out into more focused pieces.
• Are there more than 3 constructors? Sometimes a lot of constructors could be a code smell indicating using a class for different things in different places.

Anyone else have any metrics that they use? Please respond with comments below.

These kinds of things should be completely discussed on a team, and woven into working agreements, and coding standards guidelines. Teams that work within these are the most productive because everyone is on the same page and playing by the same set of rules. If your team doesn't have a guideline for these kinds of things, I would encourage you to write one up today and get input from your team.

First off, let's get something out in the open. As an agile software developer, I have a couple of strongly held beliefs.

Design isn't optional.
Architecture isn't optional.

DTSTTCPW doesn't mean "no up-front design, we'll just wing it." [That's DO THE SIMPLEST THING THAT COULD POSSIBLY WORK for all y'all who don't speak acronym.]

When we fail to refactor our new code into the existing code, we get odd bits of functionality that stick out from the existing design like warts on a bowling ball. The idea behind refactoring is that we intend to make sure that we *always* have a round ball. Refactor doesn't mean just change a signature or two. Sometimes it means we need to go back to the design white board and figure out what we need to have *now* given the current functionality requirements. We almost always need to change the existing code's design and integrate the new code so that all appears cohesive, each and every time we write new code. Iterative development doesn't intend that we make a bunch of atomic changes and just glue them together.

Code design at each check-in should be able to withstand scrutiny of any outside reviewer, and the design should be up to engineering standards. We still call it software *engineering* not software *art*. Many teams I see are missing this point completely and are producing code that should have been re-designed rather than just having new code glued on. With each check-in we should be able to look over our classes and functionality and say, "yes, this is something that would withstand the scrutiny of a code reviewer not on my team, without excuses or explanation." If I have to couch it and say "well, we will be fixing that in the next release" or "we'll revise that in a later check-in" this is technical debt, and therefore a process smell. Developers that are stuck in this rut need to be re-trained that they aren't "done" with the code until it is production-quality.

If there are warts on your software, this is a very loud process smell, and it should be addressed directly. Make sure that the team understands that this is not an acceptable way to work on an agile team. Re-design in refactoring and adding new code should be common, and discussed among the team after the stand-up meeting daily. "Yesterday I re-factored and re-engineered the Widget classes, so that they now have the new functionality we need in story XXX and are more streamlined to what we are delivering this sprint. Today I plan to have a half-hour review with the team so everyone is on the same page with the re-design. Then I will incorporate all the feedback, get the final code reviewed and coordinate the check-in with the rest of the team to make sure I don't block anyone. I'll make the appointment for the review with everyone after the stand-up."

Make sure that everyone understands that the code as a whole should be well-designed at each commit point, and that this isn't optional. It needs to be expected behavior on the team. This also means that estimation of effort may (and should) go up, for complexity on tasks in both story points and hours. We don't look at revising design as "additional work" just like we don't view unit tests as "additional work." These things are both fundamental parts of the iterative process. Without adhering to these principles, iterative development just won't work, and we might as well go back to waterfall.

If your team has the process smell of needing to budget additional work for refactoring the design, perhaps it's time to go to the team and discuss what Agile software development really means, and that it doesn't mean lower-engineering quality software.

What's your team's truck count? No, not how many SUV's do your people drive... Truck Count refers to how many key team members would need to be hit by a truck before your project fails. Not a very nice thought, but it gets the point across. It means, if a key team member leaves your team (and presumably the company) how would this adversely affect the project? Lower numbers are BAD.

About the best you can do is one less than the team size. The worst you can do is "1." Think about your project, and think about who is keeping the brain-share of knowledge. Are they passing it around the team, or does the knowledge sit under one person's cap? If so, that person makes your truck count lower and your project riskier.

Team knowledge sharing is a fine idea, but it's not always easily accomplished. We use tools discussed below for information sharing and actual knowledge transfer.

Tools
    First of all, let me just start out with: EMAIL IS NOT A TOOL FOR TEAM KNOWLEDGE TRANSFER. "Well, I sent you an email about that last week..." it's just not an effective mechanism. Don't be tempted to use it. Email should be for temporary and archival type information communicaton - NOT knowledge transfer. Here are some things that DO work.

• Wiki
• A Wiki is a good tool for a central information repository, allowing team members to add and update information easily and frequently. There are many wiki tools available, but mediaWiki currently is the leader. The ideal wiki site would allow team members to use it without having to "log in" as this is a barrier to getting the information into the site. Even more ideal would be the ability to have remote access to the site from home (with the proper security of course).
• Online team services like Rally, Scrumworks, and others
• Online team service sites allow individuals to have access to the stories, backlog, burndown, and other communication tools from anywhere. This removes a hurdle to information sharing by not requiring physical access or the hassle of having to fire up a VPN client.
  
• Pair programming, and promiscuous pairing
• Pair programming is probably the most effective way for knowledge sharing and information transfer in a team. Pair programming is an XP concept, but unlike Scrum, tenets of XP can be adopted individually on a team, rather than buying the whole program. Each tenet ads value on its own, even if others aren't adopted. Concepts like test-driven development, continuous integration, shared workspace are all good tools for development, but each ads its own value, and all are good for increasing truck count.
• Arlo Belshee calls it "promiscuous pairing" when a team doing pair programming switches pairing partners regularly, and frequently. He advocates pairing different team members together rather than the same set day after day. I have experimented with this on a highly performing team, and with the size of the team at 5 and the dynamic there, we decided that half-days were a good mix. After lunch we would switch pair partners, and information flow among the team increased without a large adverse affect on performance.
  
• Shared workspace
• Simply co-locating team members is a fine way for information sharing to occur organically. Just simply removing cubicle walls allows sounds and communication to flow freely. Removing physical barriers is an effective way to increase information flow and increase truck count.
  
• TDD game
• The pairing game is where one person writes a test, then the other person writes the code. Then, they switch. This is a very effective way to have both parties fully engaged.
  
• Code Review
• Reviewing code from other team members is a marginally effective way to get information spread across the team. I am not a big fan of code reviews, but I recognize that they are a necessary evil for those teams not actually doing pair programming. The review must be willing to put aside distractions and interruptions to concentrate on not only what changed, but also the whole of the code - making sure to understand it and verifying that it's doing the right thing.

These are just some of the things I have used for information sharing and helped my teams in distributing the brain share for a project. There are probably others as well, feel free to collaborate by adding your comments below.

Our scrum master on the team I am working with has advocated a mid-sprint checkpoint meeting, to see how things are going, and take a progress pulse. I said this sounded a bit like  to me, but that didn't go over very well. I left it at that, but was just thinking about it some more. Why would we need a mid-sprint checkpoint meeting? The burn down chart clearly shows our progress on the sprint, trend lines are good, and everyone is reporting progress and no impediments in stand-up every day. Another meeting? Sounds counter-productive to me, just to see where we are - when we should all know where we are. There are now even have a couple new wide screen monitors displaying 4 rotating web pages, used as information radiators for the team. Everything seems to be good, and going by the book for scrum, so just little things like this that remind me of my Microsoft days cause me to take pause and say hmmm.....

Perhaps a 3 week sprint is too long if we need a mid-sprint review. See the prior article for more information on sprint lengths...

Security has always been a challenge in software development. Being in an environment that has rapid ship cycles and iterative development does add challenges of its own when it comes to security.

Here are a few of the key concepts I intend to flesh out in the next few weeks:

• Security Requirements
• how to come up with security stories
• how much is enough?
• how much is too much?
  
• Using automated tools
• what tools are available
• MetaSploit - multiple vulnerabilities: http://www.metasploit.com/
• Fiddler - HTTP/S proxy, inspector, injector, manipulator. Fun for the whole family. http://www.fiddlertool.com/
  
• WireShark - network protocol analyzer and sniffer: http://www.wireshark.org/
  
• various other network tools like Snort, RetinA, NetStumbler can be automated and scripted.
  
• use static code analysis tools, and pay attention to their results.
• I recommend also doing file and network fuzzing on system entry points, but don't have any good tool recommendations. Got some? Please leave comments!
  
• web site testing vs web service testing
• application testing
  
• how do the fit into automation frameworks
  
• Security Documentation (Threat Models)
• Designing in Security as Feature 0
• Iterative Threat Modeling
• Who Reads the Threat Model?
• How do we turn threat models into automated acceptance tests?
• security testing strategies
• white route (internal folks, given the internals of the system)
  
• black route (for-hire hackers, given only an objective to accomplish, and no system information)
• security-oriented code reviews
• how to train developers and testers to look for security defects
  
• security vs. performance
• Sometimes mitigations incur a performance hit. How do we avoid this, and what are some alternatives?
  

This is an Agile blog, so this is the first production release of this article ... More features (content) will become available over time, so stay tuned to this RSS feed for updates and new content, as they emerge.

As an agile developer, I think it's fair to say that there is a bit of pressure to deliver software on a regular basis. In order to do that effectively, I need to be able to produce readable code that my team members can understand, and vice versa.

Every org I've been a part of has its own quirks about what it will allow for coding standards. The worst is when there are no standards, or they aren't "enforced." Lots of shops have these cowboy coders that love to do things their own way. It doesn't matter to them that the whole team is going to have to read, understand, and potentially update the code they are writing. The concept of "collective code ownership" is lost on these folks.

What can we do to reign in these cowboys? I proposed a coding standards guideline. It specifies in some detail how code should be written and formatted. It specifies the style, structure, and conventions. I recommended that code follow these guidelines specifically, unless there was a "really good reason" why not. "Really good" reasons did NOT include the phrase "I just didn't like it" or "I have just always done it this way." Being set in ones ways is one thing but being a professional and being part of a team is another.

Does anyone have a practical solution to this issue? If so, I'd love to hear about it... please feel free to post a comment.