Pair Programming refers to the practice of having two people engaged together on a single programming task. It’s an XP practice, and is employed by many agile (and non-agile) software development teams. Even in traditional environments where pair programmnig is … Continued
The Boy Scout Rule can be summarized as: Leave your code better than you found it. Boy Scouts have a rule regarding camping, that they should leave the campground cleaner than they found it. They don’t take it upon themselves … Continued
Respect is one of the values of Extreme Programming: Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it’s simply enthusiasm. Developers respect the expertise of the customers and vice versa. … Continued
Courage is one of the Values of Extreme Programming. To wit: We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. We don’t fear anything because no one ever works … Continued
Communication is a key value in Extreme Programming. Software projects require a great deal of communication. If you’re writing an application just for your own use, then the communication channels are all extremely fast, making for very tight feedback loops. … Continued
Simplicity is one of the Values of Extreme Programming. It guides and underlies many XP and Agile Principles and Practices. From extremeprogramming.org: We will do what is needed and asked for, but no more. This will maximize the value created … Continued
Software developers should rarely be made to work more than 40 hour weeks, and if one week does require overtime, the next one certainly should not. This helps to maintain programmer welfare and avoid a death march project.
A metaphor that everyone (whole team, customers, management, stakeholders) agrees on for how the system works.
Kent Beck created four rules of Simple Design. These are sometimes referred to as The Four Commandments or the XP Simplicity Rules. The rules, in priority order, are that code should: Pass all tests Express the author’s ideas Avoid duplication … Continued
Collective code ownership breaks down fiefdoms within an application’s codebase. Nobody “owns” a particular part of the code. Everyone on the team is responsible for all of the code. This enables pair programming and refactoring by the whole team. It … Continued