Is remote pair programming productive? Yes!

I have been successfully pair programming remotely almost every day for the last 3 years. It is very much like local pair programming with some minor differences.... OK. Some major differences, too.

Major

Instead of sitting down with your partner and sharing the same monitor and possibly the same keyboard, the screen will need to be shared virtually. There are many options including GNU Screen, iChat, Skype, yuuguu, yugma, and TeamViewer. Also, something like Google Talk or Skype should be used for voice chatting.

Minor

You know when you are talking on the phone that your attention is more focused on the conversation than when you are locally talking to someone? The same happens in remote pair programming. It is very intense and productive because both developers are extremely focused. You really need to remind yourself to take breaks, switch navigators, and go to lunch!

Labels: Agile

A couple of years ago I had the benefit of seeing agile contrasted against waterfall with the same development team on the same project. The team had recently delivered the 1.1 version of a global web application. The customer then took over the project by replacing the project manager and business analysts with people who had no agile experience.

Up until after the 1.1 release our highly productive team absolutely loved coming to work in the morning. We were eating up storing points with an insatiable appetite and pressure to perform came from inside the team. Frequently our roles would cross. Developers would help out Testers and BAs as needed and the Testers and BAs worked very closely together to document proper story acceptances.

When agile was dropped for a more traditional process, things deteriorated very quickly (teamicide). I noticed major negative consequences in user stories, project planning, management, and software development.

Stories

The agile team that was together from inception through release 1.1 benefited from testable stories with high value features. Developers worked with Business Analysts to identify tasks within a story that would require significant development time so that the Product Owner could make informed decisions on whether or not a particular feature provided enough business value to warrant the cost. The BAs also enjoyed lower cost alternatives provided by developers. Only minor changes to a story were allowed after a pair of developers started on it. Significant changes required a new story.

After release 1.1, pseudo-stories were created with many nice to have, but not critical requirements with no developer input. Story requirements changed throughout the iteration including after the story delivery.

Planning

The agile team assigned points to stories during the inception. The amount of points completed during an iteration determined the team's velocity. The average velocity over the last two iterations was used to predict release dates.

The new project manager on the post-1.1 team planned out the next four releases in Microsoft Project with no input from the developers. The releases had unrealistic delivery dates for features that were not yet defined. This is the classic "phony deadline" technique used by managers to (de)motivate developers.

Project Management

The agile project manager was deliberately inattentive to enable the team to self-organize. This resulted in very high morale because developers felt free to contribute ideas and felt a sense of project ownership. The agile project manager's primary role was to remove obstacles that would otherwise distract the team.

The new project manager micromanaged all aspects of the project. We continued to have a stand-up every morning, but as each person gave a status, the PM would ask further questions like "how much longer until the story is completed?".

Development

Pre-teamicide, pairing time was protected, the velocity was high, the code quality was good. Pressure to perform came from other developers. All of this was achieved a sustainable pace with little or no overtime.

Post-teamicide, development time was highly fragmented through frequent meetings, phone calls, and IMs. The velocity was very low and pressure to perform came from the project manager who had set unreasonable deadlines. Large amounts of overtime were required, which led to many more bugs in design and code.

Conclusion

This project thoroughly convinced me of the effectiveness of the agile methodology. It was a great learning experience, but I hope it is not repeated!

Labels: Agile

One of the extreme programming rules is Optimize Last. The rule is stated as

Labels: Agile

There have been some comments that some of you developers are very interested in adopting agile development practices, but your manager isn't seeing the benefit.

Labels: Agile, Redpoint

Be sure to attend Chicago Code Camp on May 30th at the College of Lake County (CLC), in Grayslake, IL.

I will be doing a presentation entitled TDD in the Real World. There will be a lot of real-time coding! It should be fun.

Labels: Agile, Conference, Redpoint, TDD

DTSTTCPW means not writing code to "future requirements" and not implementing the current requirements in a fancy-overly-complicated-cool-sure-to-impress-peers manner. I am convinced that many designs are driven by how cool they would look in a power point presentation rather than pragmatism!

Some examples of DTSTTCPW violation include writing unnecessary reusable code, writing unneeded highly decoupled code, writing code that goes above and beyond requirements, and introducing a design pattern into the code with no immediate benefit (e.g. strategy pattern with only one strategy). The remainder of this blog entry will focus on writing unnecessary reusable code as this is the most common mistake.

On a recent project, we were losing a lot of time trying to integrate with an unsupported web service. Up to seven people were involved from different sides of the planet. I started asking questions like 1) what does the web service do? 2) where does it get its data? 3) what business logic does it perform? It turns out that the web service was just executing a stored procedure and performing no business logic. Even worse, the stored procedure what local to our application's database!

Apparently the motivation was that at some point in the future other applications would potentially reuse this web service. Many readers of this might think that this is smart because someone was planning for the future. Most people have been in meetings or peer reviews where a developer is congratulated on his forward thinking for implementing a highly reusable design. Only a few years ago, I would have been impressed, too. Now, ......not so much. The reasons:

• Reusablity comes at a high cost - Implementing requirements in a way that takes into account other uses requires a lot of brainstorming and iterations to get right.
• You are not going to need the reusability anyway. Writing from experience, these sure to happen future requirements seldom happen. In lean terms, reusability provides no value to the customer.
• Added complexity - necessarily, a reusable design requires more complexity and probably more lines of code. This results in not only higher up front costs, but higher
  maintenance costs.
  

Common objections:

Yeah, but I once wrote this reusable code that was used by many other developers on a wide variety of applications!

• How many times did you write reusable code that wasn't reused?
• How much did the reusable code cost the customer?
• Did the customer benefit from the reusable code or just people within your organization, team, or department?
• Were other teams forced to use your code even though it didn't really meet their requirements?

Sometimes DTSTTCPW results in poor performance or non-functional requirements not being satisfied.

• Then you did not DTSTTCPW. Instead you DTSTT. Non-functional requirements need to be taken into account when deciding on the simplest thing that could possibly work.
  

Labels: Agile, Redpoint

The benefits of pair-programming include:

• Faster
  
• Fewer bugs
  
• Higher quality code (continuous peer review and brainstorming)
  
• Shared understanding of code-base
  
• Can learn from partner
  
• Better design
  
• Team building
  
• Higher confidence in code
  
• Higher satisfaction
  

Drawbacks:

• Scheduling problems (developer schedules are different)
  
• Personality conflicts
  

Most studies show that a pair is 40 to 80% faster than an individual, which means that two individuals are faster than a pair. However, the resultant code is higher quality in that it has a better design and fewer bugs. It has been extensively documented that the cost and time it takes to fix bugs found by testers or customers is many times larger than the cost of the originally written code, which effectively means that over the whole project life-cycle pair-programming is faster.

Scheduling problems can be solved, but personality conflicts can be a real problem. A good pair programmer leaves his/her ego at the door, is flexible, and most importantly communicates well. One mitigation strategy is to frequently rotate pairs.

Labels: Agile, Pair-Programming, Redpoint

One of the best ways to ensure testable code is practice Test Driven Development. How can code not be testable if it is already tested?

Another good idea is to write code that is easy to test in isolation, which is mostly done by mocking its dependencies. "Mockable" classes are achieved with:

• Injecting dependencies with an Inversion of Control framework such as Spring
  
• Avoiding singleton and static methods
  
• Favoring composition over inheritance
  

Labels: Agile, Mock, Redpoint, TDD

TDD offers the following benefits:

Labels: Agile, Redpoint, TDD, Test

Why is the adoption of Test Driven Development (TDD) so slow and why do developers not like to right tests?

Labels: Agile, Mock, Redpoint, TDD

There are still many people that believe a software project can be estimated accurately up front. Industry-wide it is commonplace that costs and delivery dates go well over what was origninally estimated by 200% or more on non-agile projects.

Labels: Agile, Redpoint

On my current project, we recently switched from Watin to BadBoy for functional testing. Watin is an excellent testing framework, but we ran into a lot of timing related "issues" because our application is AJAX intensive. A brief description of BadBoy follows.

BadBoy is a functional web application testing tool for non-programmers. It is a record-then-playback testing tool that builds up a “Script Tree” while in record mode, which allows for a variety of assertions, then in playback mode it simply runs the script and tests the assertions.

BadBoy offers Navigation and Request recording modes. Navigation mode is the traditional recording mode found in most record-then-playback tools; it records all of your mouse and keyboard activity. Request mode records just the HTTP requests and posts, which is ideal for load testing.

BadBoy is a good choice for functional testing on a project that has QA resources tasked with automated testing. If the primary functional testers are developers, a better choice is probably Watin or Watir as they are not just recorders, but they also allow for test configuration in code.

Labels: Agile, Test

While contemplating the merits of agile development it occurred to me that it is really all about less.

• Less code because only enough code is written to satisfy a Story requirement.
• Less defects while writing code through TDD.
• Less time spent fixing defects because considerable effort goes into early detection of bugs (Continuous Integration).
  
• Less regression bugs because code is protected by good unit tests with adequate code coverage.
  

Labels: Agile, Redpoint