Analyse the problem, draw up a list of requirements to solve the problem, implement those requirements, test what you’ve implemented and wish the end user good luck! The basics of any software development life cycle from conception to handing over the software to the customer, it is structured, consistent, linear and predictable. So we’re six months into developing a new revolutionary piece of software for a company that are desperately in need of a new system. We have only got a few weeks left and are half way through implementing our superb new system. Then one of our team starts a conversation with “hey what if we did this…..” you think it’s a great idea and it could exponentially improve the systems productivity. So you turn to the guy and say “Why the hell didn’t you thinking of this five months ago, we just can’t change the system one day from the next and just do what we feel could work, Its a great idea but we have 8 weeks left to do 12 weeks work, we’re already working 60 hour weeks! Right everyone back to work” so off you go back to work begrudgingly forgetting that wonderful idea -too little, too late.
Extreme Programming (XP) sees this as one of they key failures of other software development techniques, the inability to introduce new ideas at any stage of the development, being constrained by requirements set out months before. Projects ruled by meeting that all-important deadline and the whole team over worked up tight and stressed, each with their individual task to complete before the deadline under pressure not to fail. XP see this as an unproductive way of producing software.
So what is XP, how does it differ from other software development methods and why could we consider XP to be a more creative way of developing software. Firstly to define what we perceive as ‘creative’;
“Creative is to have imagination and to be able to think originally, to express creativity is to apply these skills within a specific area for example painting or composition of music” [Oxford Dictionary {D N}]
You could argue that any software development project has creative merit, as building software always requires a sort of creativity so any software development technique involves an artistic component. This may be true to an extent but software development methodologies like Structured Systems Anaylsis and Design Method (SSADM) and the Rational Unified Process (RUP) are specific to what needs to be constructed in the analysis stage before implementation (coding) has taken place. This is like composing a song without touching a musical instrument, thus setting what is to be built before trying to build it limits the creative scope!
XP promotes a different way of approaching software development by shifting the emphasis from analysing the problem as the key activity in software development to the actual implementation (coding) of the software. XP is a test driven software development technique, testing is the primary activity which XP relies upon. XP puts forward the philosophy of if you can’t test it doesn’t exist;
“Any program feature without an automated test simply does not exist. Programmers write unit tests so that their confidence in the operation of a program can become part of the program itself. Customers write functional tests so that their confidence in the operation of the program can become part of the program too!” [Kent Beck 1999]
When the actual development takes place XP says that the programmers should compose the test classes before they start to write the subject code that the test are for. XP calls this a “test-first” programming method. By doing this eXtreme Programmers believe the approach benefits the development by making their code more testable and therefore more measurable.
“Test-first, because we write automated, repeatable unit tests before writing the code that makes them run, this approach yields several benefits; The code is testable, the tests are tested, the tests are repeatable and its easier to produce documentation from the tests results” [William C. Wake 2001]
So how could we perceive a test-first approach as a more creative way of developing software, well firstly it appears similar to other methodologies as it is defining what we want to construct before actually constructing it. How it differs from other methods as XP works on a day to day basis thus these pre-built tests are written regularly therefore if anything changes within the development life cycle the tests can be altered to fit a modified set of properties. XP has its critics but on the evidence presented by using a test driven process critics praise XP for this centralised view of a test-first development strategy.
“An increased emphasis on unit testing and on the use of automated testing tools is probably the most useful benefit to emerge from the XP phenomenon.” [Matt Stephens, Doug Rosenberg 2003]
XP employs a different view on how software should be implemented, conventional methods such as SSADM see the construction of software (coding) as an activity, which is subdivided into modules and assigned a programmer who individually works on that module. XP proposes a different way of writing code – Pair programming, two developers working at one computer system on the same module.
“Pair programming is the practice of having two people working together to design and develop code. They are full partners, taking turns in typing and watching; this provides constant code and design review” [William C. Wake 2001]
This benefits the creative aspect of software development as it improves the ideals of original thinking as if two people are working on the same module they have the opportunity to share ideas between each other and constantly review their work. This exercises the idea of collective ownership for the given project and pair programming aids this as no one person is responsible for a particular module of the project but everyone is collectively responsible for the whole project.
Criticisms of pair programming consists of firstly not every programmer is suited to pair programming, XP defines pair programming as a mandatory requirement for a XP based development so a programmer who likes to individually work on code is unable to do so. Pair programming is dependant on the pair having similar skills and abilities or else one half of the partnership could be made redundant as the other does all of the work, this is called ‘go make me a cup of tea syndrome’ [Matt Stephens, Doug Rosenberg 2003]. Another issue with pair programming is it can cause loss of expertise as programmers work on everything so that everyone has a sort of understanding of every module within the project but may lack depth of specifics.
“In XP, everybody takes responsibility for the whole system. Not everyone knows every part equally well, although everyone knows something about every part” [Kent Beck 1999]
Though the above quote is illustrating a positive point about XP it also highlights a possible issue off loss of expertise as if everyone has knowledge of every part no one person can claim specialized skill and expertise this also supports an argument against implementing a collective ownership policy as no one person can be seen as responsible for a particular module.
XP prides itself on the idea of having an “on-site” customer, most software development methods believe in having a strong customer relationship so that the end user can explain to the development team what the software needs to do. XP takes this idea to the extreme by pushing the idea of an “on-site” customer available at all times for the developers to query on matters concerning the system and help combat problems which arise during development. XP defines the customer as the persons, which the system will be operated by;
“If you are building a customer service system, the customer will be a customer service representative. If you are building a bond trading system, the customer will be a bond trader. The big objection to this rule is that real user (customers) of the system under development are too valuable to give to the development team” [Kent Beck 1999]
This idea seems extremely beneficial to the development team but from the business point of view it could be seen as an unproductive use of human resources as it requires an employee of the business being taken out of their working environment into a situation where for some of the time their role will be redundant and their presence may be unwarranted.
One of the problems this could generate is if there are more than one type of customer who will operate the system. This is because XP relies on a singular “on-site” customer so having more than one customer causes confusion and enhances the chance of the project failing. Take for instance the first project XP implemented which was the ‘C3′ project (Chrysler Comprehensive Compensation). The project aim was to develop a payroll system, XP came into existence when Kent Beck the pioneer of XP was bought onto the project as a software developer in 1996 and he introduced several ideas, which now make up the basic core principals of XP. In February 2000 the project was unexpectedly cancelled by Chrysler, Kent Beck then went on to explain why the project failed by saying;
“Near as I can tell the fundamental problem was that the ‘Goal Owner’ (the person who instigated the project for example managers) and the ‘Goal Donor’ (the person XP sees as the customer) weren’t the same. The customer feeding stories didn’t care about the same things as the managers evaluating the team’s performance”[Matt Stephens, Doug Rosenberg 2003 Figure 2-6]
The critics of XP also claim that the ‘C3′ project failed because of a combination of problems generated by XP methodology. XP relies on releasing small and frequent releases this is considered one of XPs main strengths along with continuous unit testing. The C3 project saw the first implementation of these short incremental releases. When faced with this XP function within a real world situation, within the C3 project the development team found that these releases were unobtainable as in the circumstances it was impossible to implement the system to a small proportion of users. Ron Jeffries who was a software developer who worked on the C3 project as the XP coach (a role which required him to lead the team and keep the project on track) posted a message on rational.com about the reasons he felt the C3 project failed;
“One of C3′s possibly-not-minor problems was that we did not release the payroll incrementally because no one could see how to do half a population” [http://www.rational.com 2000]
XP keeps it simple, XP believes that if you find the simplest solution to a problem it will provide the best solution, as XP promoters have a philosophy that it is better to build something simple without adding extra functionality which may prove to be unneeded in the final system. They also believe by doing this it improves the maintainability of the system if the code is simpler to understand it will be simpler to modify. With this in mind XP as a software development technique which has been tailored around the use of object orientated design.
XP brings a new dimension to invoking a software development methodology; it promotes a number of alternate ways of approaching key practices that take places within a regular system development. An aspect of XP which evens it critics agree upon is the idea of a test driven development process this is a highly desirable characteristic as it improves the quality of the code produced thus improving the reliability of the project.
So why could XP be consider a development, which promotes creativity. Well the main argument lies within pair programming, based on the principle that if two people working on the same piece of work inspires them to be more creative, a counter argument to that is by forcing developers to program in pairs takes away the individual creative ability of the developers.
“People in creative programming don’t pair. Remember too many cooks spoil the broth. Can you imagine two painters creating a masterpiece by taking turns with a paint brush?”
[Matt Stephens, Doug Rosenberg 2003 Figure 2-6]
Though in some ways this argument is valid, others such as Kent Beck would argue the opposite as he believes pair programming increase’s creative productivity and that the example given above is limited as Stephens and Rosenburg only draw comparisons with creating a painting, this is only type of creative practice, which is historically an individual activity. Johnson and Johnson investigating how XP can be compared and contrasted related XP to the composition of a piece of music.
“In particular we emphasize how pair programming can facilitate an increase in the overall skill level of individuals and teams, and relate this to musicians’ development of models of excellence through ensemble playing. Consideration is also given to the psychology of music performance and its relevance to the pursuit of excellence in software development.” [Andrew Johnston and Chris S. Johnson 2007]
XP in the real world paints a slightly different view of its use. In practice XP requires an exclusive set of developers who are highly motivated, well experienced and have superior communication skills. This is because the XP work environment relies on self-motivation and expertise. XP also requires the developer to be able to adapt to a different way of developing software.
XP brings numerous advantages to the development, specifically within the design and implementation stage as XP is centered on the creation of software. But in our estimation XP lacks the analytical tools, which other software development methodologies possess such as SSADM, these are vital tools in most software development projects. Because of this XP would profit from being paired with another software development methodology so that the impact of pitfalls in analysis XP presents is lessened.
VN:F [1.9.3_1094]
Rating: 4.0/5 (1 vote cast)