What is Pair Programming?

Pair Programming is an innovative concept of two people sitting together at a single terminal and tries to produce a solution. One person types the program tactically while other person thinks strategically. This approach will produce same functionality when compared with two different people sitting at two different terminals. Researchers reassure a high quality product with pair programming methodology.

Pair programming encourages pair-analysis and pair-design to have smooth product delivery. Pair-analysis should include development directions and strategy outlines during complete cycle. As two brains works together, there is always a better chance of yielding a good solution rather than a simple solution. Pair-design helps to outline the defect defects in a very early stage, reducing defect tunnel vision. With the partner discussing on top of other developer’s vision, programmers will have a better understanding of the requirement. After design is completed, pair team starts their implementation. One of the developers will be in driver seat and other will be strategic controller. Unit testing will be performed after pair development by having developers develops test cases together and executing the results.

“Organizations that have heavily used pair-programming have yielded superior results. The largest example is the sizable Chrysler Comprehensive Compensation system (the C3 project discussed in Ron Jeffries’ story above) launched in May 1997. After finding significant, initial development problems, Beck and Jeffries restarted this development using Extreme Programming principles, including the exclusive use of pair-programming. The payroll system pays some 10,000 monthly-paid employees and has 2,000 classes and 30,000 methods [9], went into production almost on schedule, and is operational today. In the last five months before the first production, almost the only defects that making it through unit and functional testing were written by someone programming alone. Says one pair-programmer in an anonymous survey [10] of professional pair programmers, “I strongly feel pair-programming is the primary reason our team has been successful. It has given us a very high level of code quality (almost to the point of zero defects). The only code we have ever had errors in was code that wasn’t pair programmed . . . we should really question a situation where it isn’t utilized.”

Laurie Williams, Robert R.Kessler, Ward and Ron performed an experiment in class producing quantitative results supporting the pair-programming results in industry. The students completed four assignments over a period of six weeks. Thirteen individuals and fourteen collaborative pairs completed each assignment. The pairs always passed more of the automated post-development test cases run by an impartial teaching assistant (see Table 1 below). (The difference in quality levels is statistically significant to p < .01.) Their results were also more consistent, while the individuals varied more about the mean.

Individuals Collaborative Teams

	Individuals	Pair – Team
Program 1	73.4%	86.4%
Program 2	78.1%	88.6%
Program 3	70.4%	87.1%
Program 4	78.1%	94.4%

Table 1: Percentage of Test Cases Passed

Advantages of Pair Programming

Errors are identified upfront. This reduces the cost of software maintenance significantly. Design reviews are part of regular pair discussions, which helps in making the design simple and reduce of re-factoring. Pair-programming encourages cross-training between developers.

—

Pavan Kumar Gorakavi

LDAP – Relative analysis of opensource LDAP

Check my presentation for 2^nd International Conference on LDAP  LDAPCon 2009. @http://www.symas.com/ldapcon2009/papers/gorakavi1.shtml

D-SCRUM

My presentation on D-SCRUM @ 3rd Annual Project Management Symposium,University of Texas at Dallas.

http://som.utdallas.edu/graduate/execed/projectMgmtProg/projSymposium/

Principles of Agile

Agile methodology has primary focus of Individuals and interactions, Working Software over comprehensive documentation, Customer collaboration over contract negotiation, and responding to change over following a plan. We can summarize following principles that differentiate an agile process.

Customer Satisfaction

An agile process facilitates the customer to have a quick view of the product. Agile process delivers early and often. As a rudimentary system is provided with in first couple of weeks, Customers has chance to make requirement changes if they feel that what they see doesn’t match with what they envision. Requirements changes dynamically but they strictly adhere to deadlines.

Good team with higher accountability

As agile methodologies are rapid in nature, a team of good players needs to be accommodated.   Though all players need not be strong players, players with higher accountability and user involvement is imperative. The team should comprise of developers, customers, and any other business related personalities. The team should be empowered to make decisions.

Light weight requirements, flexibility for rapid changes

Requirements have to light weighted. We can expect change in requirements late in development process. It should be noted that requirements evolve with fixed time scale. This differentiates agile methodology with conventional development methodology. Generally industries go with 80-20 acceptance policy.

Small and Iterative cycles

“Eating an elephant, one Bite at a time” policy should be implemented when we focus on agile methodology.  Agile methodology advises to develop project in a small size with an incremental nature. Agile is iterative in nature. This nature reduces the risk of what you see vs. what you envision aspects. It also provides effective cost management, and less re-factor cost. Deliverable are given preference over documentation.

High degree of communication

There should be a high degree of communication between the team members in    order to apply agile methodology effectively.  There should be significant interaction between the customers, developers and stakeholder. Just-In-Tme [JIT] methodology has to be implemented for successful practice of agile methodology.

Frequent releases/deliveries

Agile methodology is incremental in nature. A rough draft will be available   to customers with in first couple of weeks. The agile projects are mostly of length 2-3 months or even less than that. Agile advices for incremental delivery system with shorter cycles of development. Cycle size can varies based on consensus,    size of the project, and environment of the project.

Early Test, Early feedback

Agile team includes developers, testers, and stakeholders. As testers are integral part of testing, unlike traditional methodology, testers can test the modular functionality in parallel to development. Early delivery yields early feedback, which opens an option to compare what customers see vs. what they envision. This kind of approach reveals implementation difficulties at an initial stage, which provides an opportunity to renegotiate requirements.

—

Pavan Kumar Gorakavi  M.S, M.B.A, C.A.P.M, G.M.C.P

Agile methodology

What is Agile Methodology?

Agile denote nimbleness, is a light weight development methodology which based on iterative development where solutions evolve from tightly collaborate cross functional teams. In early 2001, when many people have hard time in identifying a methodology which delivers a product quickly and with good responsive index, a group of Industry expert forms into an alliance called themselves as ‘Agile Alliance’. Over two days they worked to create statement of value, which results in the manifesto of agile alliance. Over next three months they formulated the principle of agility.
The Agile movement observes the light of day with agile alliance manifesto. This manifesto primarily focuses on the following aspects:

• Individuals and interactions over process and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Respond to change over following a plan.[1]

Human resources are most important aspect for project success. Human resource and high degree of interaction between the resources can make a process success. Even a group of strong players can fail in yielding the results, if the degree of communications or team play fails. Excessive documentation or limited documentation can hamper the success of the project. Optimal documentation has to be provided as landmark for project guidelines. Successful projects can be implemented when customer is collaborating during contract negotiation. Successful projects involve customer feedback on a regular and frequent basis. In Agile methodology, customer works closely with development team, providing frequent feedback, which results in developing as-expected product. Agile methodology provides an ability to respond to change that determines the result of the project. A good planning strategy has to be include as part of this methodology, to accommodate sudden change in plan.

Cockburn(2) states Agile methodology as light and sufficient rules of project behavior and use of human and communication oriented rules. Cockburn propose the following ‘sweet spots’ which enhances the outcome of project.

• Modularity on development process level
• Iterative with short cycles enabling fast verification and correction
• Time bound with iteration cycles from one to six weeks.
• Parsimony in development process removes all unnecessary activities.
• Adaptive with possible emergent new risks.
• Incremental process approach that allows functioning application building in small steps.
• Convergent and incremental approach minimizes the risks.
• People oriented
• Collaborative and communicative working style.

Highsmith and Cockburn reports software development process is directly impacted by changing environment. To satisfy the customers at the time of delivery has taken precedence over satisfying the customers at the moment of project initiation. According to Cockburn, agile methods are designed to: produce the first delivery in weeks, to achieve an early win and rapid feedback.Invent simple solutions, so there is less to change and making those changes is easier.Improve the design quality continually, making the next iteration less costly to implement, and Test constantly, for earlier, less expensive, defect detection.

Ambler [4] summarizes agile methodology as a people matter, with less documentation, communication provides pivotal role, and modeling tools are not much useful and big upfront design is not required.
Boehm[5] analyzes agile methodology as component module with agile knowledgeable developers, dedicated and collaborative customers, rapid change requirements, in-expensive re-factoring and smaller teams and product, with primary object as ‘Rapid Value’. He made some significant analysis of agile methods, open source software, and plan-driven methods.

In a nutshell, we can summarize agile methodology as an incremental process, which yields successful product in a highly communicated dynamic environment.

—

Pavan Kumar Gorakavi

M.S, M.B.A, C.A.P.M, G.M.C.P