XP essentials: What makes Java projects more successful

Object-oriented programming with the Java language has become ever more pervasive. It has led to some change in software development, but recent research has shown that half of software development projects lag behind, while one-third of projects are beyond budget. The problem is not the technology, but the method used to develop the software. The so-called "lightweight" or "flexible" approach, combined with the power and flexibility of object-oriented languages such as Java, provides an interesting solution. The most common form of flexibility is called Extreme Programming (Extreme programming) or XP, but many people do not really understand it. Using XP for Java projects can greatly increase your chances of success. This article provides an overview of XP and explains why it's important--not rumors, no scams.

Over the past decade, CEOs have been under a lot of pressure to generate steadily higher incomes. They solve the problem by taking a series of initiatives in many ways, such as shrinking the size of the company, outsourcing, re-engineering, enterprise Resource Planning (ERP) and so on. These inefficient solutions have allowed many companies in S&p 500 to maintain double-digit revenue growth for several years in the late 90. But this approach has also brought some negative effects.

In Gary Hamel's leading the revolution (see Resources), he claims there are signs that the advantages of traditional business models are less obvious. We must find alternative ways to provide momentum for sustained revenue growth. He suggested that the only way to keep the company growing was through a radical innovation. We think this is particularly necessary in the area of software development.

Corporate issues

If you use a standard software development approach, be prepared to be disappointed even if you are developing on a Java platform. As shown in Figure 1, recent studies have shown that half of the projects will lag, while one-third of projects will exceed the budget. This is much better than the results of the 1979 study by the United States General Audit Office.

Figure 1. Software project success and failure, past and present

If we want these numbers to improve significantly, we need radically innovative ways to develop the software. There are two main factors affecting the existing approach:

1. Fear of failure

2. Misconceptions about the nature of software

No one is going to fail. The irony is that the method created to minimize the failure is unsuccessful. The misunderstanding of software is the root of the problem. Fear is actually just a symptom. The existing approach is created by those smart people who have a good desire but forget the "soft" of the software. They assume that developing software is like building bridges. Therefore, they draw from a variety of design specifications for a number of "hard" objects (such as bridges) the best method. The result is a slow-developing approach based on the idea of big design up-front (BDUF), where software is vulnerable and people cannot use them.

A solution: A flexible approach

There have been some recent shifts from the so-called "weight" approach to "lightweight" or "flexible" methods such as the Crystal approach, adaptive software development and (currently the most popular) XP. All of these processes have the fact that people need to work together to develop software. Successful software processes must maximize people's strengths and minimize their shortcomings, because there is no doubt that the pros and cons exist. In our view, the best thing about XP is that it solves all the complementary forces that affect the participants.

XP offers the biggest opportunity in decades to revolutionize the software development process. As Peopleware writer Tom DeMarco said, "XP is one of the most important sports in our field today." It is expected to be of importance to the current generation as the SEI and its ability maturity model are important to the previous generation. ”

XP sets out a set of core values and methodologies that allow software developers to play their expertise: write code. XP eliminates the unnecessary artifacts of most heavyweight processes, deviating from the target by slowing down development and consuming developer energy (such as a dry-figure, status report, and multiple-volume requirements documents). We recognize that something called "extreme Programming" may be difficult to recommend to management as a formal development process, but if your company is engaged in the software industry, you should help management bypass its name to recognize the competitive advantage that XP can offer.

Kent Beck outlines the core values of XP in his book Extreme Programming Explained:embrace Change (see Resources). We have summed them up:

The problem with communicating projects can often be traced back to someone who has not consulted with others on some important issues at some point. Using XP, not communicating is impossible.

Simple XP recommends that you always do the simplest things around the process and writing the code as much as possible. According to Beck, "XP is a bet." It bet it's best to do something simple today ... Rather than doing things that are more complex but may never be used. ”

Feedback earlier and often specific feedback from customers, teams, and actual end users gives you more opportunities to adjust your strength. Feedback allows you to grasp the right direction, less detours.

Courage and courage exist in the other three values of the environment. They support each other. It takes courage to believe that concrete feedback is better than knowing everything in advance. It takes courage to communicate with the rest of the team when it is possible to expose your ignorance. It takes courage to make the system as simple as possible and to push tomorrow's decision to tomorrow. And if there is no simple system, no continuous communication to expand knowledge, without the control of the dependence on the direction of feedback, courage will lose its reliance.