As per my previous blog, C3 was the abbreviated name of the Chrysler Comprehensive Project, which was a payroll project at the car manufacturers; it has since become known as the ‘birth of Extreme Programming’ (XP). C3 was an effort to replace the corporations existing processes and British born software engineer Martin Fowler began working as a consultant in 1993 whilst the project was gathering some noteworthy momentum, it was then guided under the expertise of Kent Beck from 1996. This project coordinated what would become knows as XP (Extreme Programming); Kent had however worked with a similar vision on previous projects. In 1997, when the software was rolled out for use in Chrysler, it did manage to pay about 10,000 of the company’s employees; this was only 1/9 of the total workforce at the time however. Whilst it was envisaged that XP would process a larger proportion of Chrysler’s payroll requirement, a decision in 1999 was made to halt the software’s development within that company.
Despite the teething problems associated with the c3 project, the perceived early success of XP in paying the employees, kick-started other projects which by now had emulated C3’s goals; this ensured that XP would develop further. It should also be noted that the decision to halt c3’s development proves that XP’s success cannot be taken for granted.
Kent Beck went on to edit a number of publications; most notably ‘Extreme Programming’ (1999). Extreme Programming did veer from its initial usage into a variety of disciplines in the late 90’s and at the turn of the millennium. As the original practices required a high level of discipline, this was not being adhered too as rigidly then. Integration testing (I and T) was originally done at the end of the working day and this was now on occasion completed at the end of a particular week or longer in some instances. It could be argued that this less regimental approach gave the software developers more time to work on more projects with a higher complexity. In Kent Beck’s 2004 publication ‘Extreme Programming Explained’, he made a distinction between primary and corollary practices and he further added more practices to the process involved in XP’s development.
There are a number of key concepts involved in the working of XP programming;
Extreme Programming lists four core activities, which are undergone during the tenure of the development of the software; designing, testing, coding and listening.
XP believes that without code, there is no working product at the end of the process. Coding can properly communicate programming shortfalls; it can find the best solution for the problem at hand. Coding in its simplistic form can fix complex problems.
In his book ‘Extreme Programming Explained’, Kent describes XP as software development, which helps the developers to work to achieve a better-quality software. Financially, the use of many shorter development cycles reduce the costs as opposed to the burden of longer cycles, which can be hugely expensive.
Acceptance testing confirms that the customer’s needs are met by the developers of the XP program.
XP utlilies unit tests; thus looking to establish if a given feature actually works. The software developer writes automated tests in an attempt to ‘break’ the code. The code is complete should all the testing prove successful. As mentioned above, integration testing is encouraged in a bid to discover any non-workable interfaces. Nowadays, the system integration is not done daily, it can be done weekly, fortnightly or monthly.