eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers [Electronic resources] نسخه متنی

The 4 (+1) Key Values

As previously mentioned, the four key values of XP are communication, simplicity, feedback, and courage. Kent Beck, one of the creators of the term eXtreme Programming and author of the first book on XP, has also added respect as the fifth of the key values. The following subsections briefly discuss each of these values.

Communication

Problems often result because people are not communicating. This is especially true in efforts that are team focused, such as software development. When the team is not openly communicating, the information flow that keeps the team moving forward is damaged.

Bad communication happens for a reason. Communication is not generally seen as an important skill for developers to obtain. In fact, many developers have previous poor experiences of communication. Managers often do not want to hear what is being said. Other developers have their own issues to contend with and do not want to hear about your issues. This experience does not encourage developers to speak out when things need to be said. A few of these experiences may lead to an environment in which communication is at best limited and at worst nonexistent. A junior developer joining such an environment would not know anything was amiss. His lack of experience could lead to the belief that poor communication is how software should be developed.

The proponents of XP (myself included) claim that communication is vital to develop software of value. The information flow created by ongoing communication allows all members of the team to contribute to the final results. This enables a group of individuals to behave as a team with the goal of developing great software.

Many of the XP practices force communication to be prevalent among the development team. Some of these practices such as the planning game, pair programming, and stand-up meetings are obvious mechanisms, but others such as coding standards and refactoring also lead to greater communication, as you will see in later chapters. An XP team uses the role of the coach to police the communication, ensure it is occurring, and encourage the use of practices to overcome any barriers.

Simplicity

"What is the simplest thing that could possibly work?" is a cry often heard in XP teams. This means to do the simplest thing that will enable you to move forward in the right direction.

Simple is Smart I often equate the value of simplicity with math problems. I remember at school struggling with a few tricky equations, and then slapping myself on the forehead when I found the answer (because it was so simple). It often takes real genius to create a simple solution from a complex problem. Most people create a complex solution from simple problems and think they must be pretty smart because of the complexity they have created. In fact, the aim is to be as close to genius as possible and try to create simple solutions for the most complex problems. On my own, I have a lot of difficulty trying to be a genius at any time, but with a team of smart people, we can get a lot closer to genius on a regular basis.

Don''t plan the future! The future will happen regardless of whether you plan it. By planning the future, you are always avoiding the present. You are avoiding the present now by planning. You are avoiding the present that will be by focusing on where you are in your plan. A common response I get to this is a declaration of my madness. "Of course you have to plan for the future and design the system first; otherwise, how would you ever be able to write the code? Don''t be crazy!" This is so difficult for developers that it is one of the biggest hurdles to overcome when moving into an XP environment.

As you will learn in this book, XP does not promote detailed upfront design of the entire system. The design is done a small part at a time, allowing for greater flexibility in the software being developed. By developing one small piece of functionality at a time, testing first and constantly refactoring, you do not need to design the system; it will design itself! The designs will emerge as an outcome of taking a disciplined approach to using the practices. The team needs to have experience with object-oriented coding and design patterns so that they can see these patterns emerge and work with them. For this reason, tools such as UML are still incredibly valuable; they enable communication of the patterns as they emerge in the system.

The point of keeping things simple is to code for now rather than never. By this I mean that we should code to solve today''s problems for your customers, not problems in the future that might or might not come up. Doing this gives you a far greater chance of solving those problems more rapidly and providing the customer with some value in the short term. If every day you produce something of value for the customer, then after several weeks the software you are building will have a culmination of all that value. This is often a sticking point for developers.

To see how this is possible, you need to understand how the practices enable us to treat the code in a different way than traditional approaches. The unit tests provided by TDD and refactoring techniques enable us to change code more readily. Creating a more fluid code base means we do not need to be concerned if the decisions we make early on are absolutely correct. We can change the design of the entire system more easily than ever before.

This simple code that you (and your team) have written will ship quicker because less can go wrong. Shipping more quickly enables you to get the value to the customer more rapidly and solicit feedback (see next section) more readily.

Simpler code means less to communicate. By keeping the solution as simple as possible, you are aiding the first value we discussed. Having less to communicate means it is easier to communicate and explain what the code is doing and the emerging design.

One final point: Simple does not mean easy. Developers who are starting out often misinterpret this as "Do the easiest thing you can possibly do." This is incorrect; simple is often a lot harder to achieve than complicated. As you work through this book, you should start to see how by keeping the task you are working on simple you can build more complex solutions. An example presented later in this book is replacing a switch statement with polymorphic behavior. The switch statement is easier to write, but the polymorphism provides a simpler solution.

Feedback

Feedback on your progress enables you to adjust your actions to better meet the goals of the project. Feedback leads to a greater understanding of the state of the system being developed. This understanding tells you exactly what you have done right and what you need to work on. Knowing what you need to work on is incredibly valuable. The feedback acts as a guide for the next set of tasks. Understanding an issue early often averts a potential crisis later on.

If you ask an XP team how they are coming along, you might get a response such as "don''t ask me, ask the system." XP teams build feedback systems into their software using tests, profiling tools, and automated builds. The results from these are generally posted in very public places, providing feedback on their progress for all to see.

The granularity of the feedback cycles goes from minutes to months. The following identifies some of the practices that support these different timescales.

TDD Developers drive the code development by writing tests first and then the code to make the tests pass. This leaves test code in the system that provides feedback on the stability of the system. An XP team will receive this feedback at intervals of minutes as they work on the code throughout the day.

Customer user stories The practice of letting customers define the functionality their users require on story cards, typically index cards. These story cards are discussed further with the customer when the time comes to implement that functionality. This provides the customer with up-to-the-minute feedback on what is being worked on. (Customer user stories are discussed more in the next chapter.) Most customers will check completed stories daily.

Stand-up meetings When a customer story is completed, the customer is informed. Often the customer will get a demo of the system within a day of a story being completed. This helps to obtain more rapid feedback. The meetings occur daily, and so again this is daily feedback.

Short releases Within the first month or two, an early working version of the software should be ready to ship. This is a goal that every XP team I have worked with has managed to reach. This shipment might be to only a few friendly parties (usually chosen by the customer). Shipping will allow the developers to receive feedback as to the usefulness of the system being developed and the correctness of the functionality. The timeframe for feedback from short releases is in terms of weeks and months.

Ship it Quick, Ship it Often Until it ships, you know nothing! I have personally worked on projects with large scopes where the business needs were not clearly understood. The project managers refused to give the customer anything early on in the development life cycle. The managers would say, "It''s not ready, and they won''t understand that these functions are missing." This was a flaw in the development life cycle. The development team was coding blind. If we had given the software to the customers earlier on in the process, we could have received feedback on our progress. We were not getting feedback from what we had already developed, and this ultimately led to a failure in the project delivering what the customers wanted. It is worthwhile shipping the simplest system that makes sense. This simple system forces feedback from the customer, and you can use that feedback to improve the software.

Simplicity, communication, and feedback create a self-supporting cycle; feedback leads to more communication, communication leads to understanding what to test, simple systems are easier to test, easier to test means more feedback, and so on, as shown in Figure 1-1.

Courage

To use the practices prescribed by XP and get the full value from doing so takes courage. Many of the practices are difficult, and if taken at face value, they don''t seem to make sense. It is this courage to take up the practices and make the results happen that contributes to the extreme in XP.

By employing the safety harnesses provided through the use of the practices, developers can increase the intensity of their work. They can go fast and furious at cutting code that solves the problems at hand. By doing this, developers will find they get more produced but may tire more easily; this is called upping the burn rate and lowering the hours. It is about working hard and fast while at work and then getting out to relax and enjoy life. All of these things take courage to do.

Other aspects that require courage include making changes when needed, not before, and being prepared to throw code away. Both of these practices are alien to many developers and might require a change in the way you think about the code you are writing. As mentioned previously, one of the themes of XP is to lower the cost of change. Writing code that we might need in the future actually increases the cost of change. Code you do not need now is code that we are not using but that needs to be changed. The cost of change can be lowered by not including code until it used. The tests help us to validate this; if we find code that is not being used, we should throw it away because it is encumbering the system needlessly.

Employing just courage alone without the safety nets and harnesses provided by the other values and through following the practices is dangerous, often lethal, to the project. Take care and allow your confidence to grow as you follow the practices so that you can have the courage to communicate new ideas. To ensure these new ideas, keep the system simple. Experiment with new ideas and get feedback on new ideas. These ideas will become the code in your software.

Respect

One of the [6] as "flipping the bozo bit"; each team member has a bozo bit. Initially, none of us is a bozo, and the bits are all off. When you flip the bit on, that person becomes a bozo and has to work hard to switch the bit off. It is important to respect our fellow team members and