Ruven, > Far from being the next great thing in software development, I'm more > inclined to think that Xtreme Programming is that bright flash that > occurs just before a light bulb burns out. The group I am in follows > many of the practices of Xtreme programming; while they are certainly > worthwhile and probably better than other practices, their overall impact > on our project has been modest. I do not think I can disagree with this, eXtreme Programming is really just a formalization of best practice using the system development tools of the 70s and 80s -- whilst Java is a good programming language it, and C++, are notations based on 70s and 80s concepts of computer-based systems. > The central issues is that Xtreme programming is heavily focused > on the code and the process of coding, including code design (as versus > application design). That's not where major software development problems > are today. The danger we risk here is getting too focussed on one issue. As I noted earlier, programming had been a neglected aspect of systems development. Ideas about software architectures are settling down having been the fad of the recent past. Patterns are no longer a fashion more a solid tool for supporting design. The issue is not focussing on programming or requirements capture (I note that BCS are now pushing the requirements capture line with respect to course accreditation), the issue is getting the right balance. eXtreme Programming is, I agree, not everything but it is (for me anyway) a good approach to teh implementation end of things. > 1. Determining the requirements continues to be the dominant problem in > software development. It is the biggest cause of schedule slippage during > development and the biggest cause of product failure after delivery. > Great software architecture, terrific coding skills, and superb debugging > ability are, at best, a weak defense against requirements changes. > Xtreme programming has little to say on this front. A not often mentioned > fact about the Chrysler payroll success story is that another group > had already spent 3-4 years establishing the requirements. The Xtreme > programming group only got their chance when management decided that > the other group wasn't making progress - because no code was rolling out?. I agree that dealing with capture and evolution of requirements and user expectations in an environemnt where the requirements change daily (or more frequently) is the dominant problem of the moment. Well it has always been the problem but now people are trying to deal with it seriously. > In fact, although phased development can provide early prototypes to > show to users, Xtreme programming advocates recommend against showing > prototypes to the users because it raises expectations!! I have always said that the eXtreme Programming orthodoxy was way too extreme. The idea of zero documentation is another of my disagreements with the orthodoxy. > 2. Even in the software development proper, the biggest problems > today are probably in the area of installation and deployment, not in > code writing. The "bugs" that crash telephone systems are not bugs > in the code, but errors in the configuration data that are loaded into > the programs. Similarly, the biggest problem in product support for my > company are install problems; if it won't install, who cares whether it > has bugs or not? Again, Xtreme programming considers deployment to be > some else's problem. Whilst I agree that the configuration data is often the problem, I would argue that if the code does not protect against bad data then the program is either incomplete or poor (depending on whether it is at the early stages of development or released to the world. Systems should protect themselves against the vagiaries of the outside world, ones that do not should not pass the acceptance test. > 3. Xtreme programming seems focused on "green field" development, > writing a new program from scratch. This is a declining activity. > Few corporations can afford the luxury of doing what Chrysler did and > writing their own payroll program. Instead, most companies focus on > acquiring and using an existing package for this kind of application. The > job market reflects this trend. C++ programmers are a megadollar a dozen, > but an Oracle or SAP consultant can command an annual salary in the six > US$ digits. I am not sure that this is true. Perhaps the most rigidly orthodox version of eXtreme Programming is designed at knowing the system from the outset but this does not stop the good parts being used as a process for evolving an extant system. The added bit is the "learn about the extant system" -- which is hard. University courses are really going to have to tackle this sooner rather than later. I like to believe that at KCL we are tackling this now. > Certainly, it is possible to go to far in the opposite direction and > totally neglect the software architecture and code in favor of contextual > inquiries into user requirements, organizational deployment planning, etc. > In this rare case, > Xtremem Programming might well be project salvation. Extremism is anathema in most Chinese philosophies. I think they have a point. Perhaps we need create a new paradigm of good practice and label it Programming. This of course brings us to the real crux: what is it that makes some people good and some people bad at programming. Certainly it is true that people who can get firsts in Management, Maths, Physics and Chemistry can be very mediocre at programming, software engineering and system development in general. There is also the problem that programming is seen as hard whereas analysis and design is the easy option that anyone can do. Requirements capture, analysis and design are seen as the soft side of development whereas software engineering/programming are seen as the hard technical (and hence difficult) side of development. Is this true? Do we know what makes people good at any of these? Speculating wildly: If we could construct a test that was a good predictor of good programming we might know more. Certainly such a test could be used as a filter as university level and thereby lower the appalling wastage rates in computing courses. This would then help raise the quality of university output and ameliorate the shortage of good development staff in commerce, business and industry. Russel. ======================================================================== Prof Russel Winder Professor of Computing Science Head of Department Department of Computer Science Phone: +44 20 7848 2679 King's College London Fax: +44 20 7848 2851/+44 20 7848 2913 Strand, London WC2R 2LS [EMAIL PROTECTED] UK http://www.dcs.kcl.ac.uk/staff/russel/
