[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Extreme Programming goes mainstream?
One of the basic characteristics of XP is that it advocates an adaptive approach to engineering software rather than a predictive one. It recognizes that up-front analysis is often speculative. Requirements change. And so it has a built-in "error correction" mechanism. But what is interesting is that this unpredictability extends to software that has already been released. In a truly adaptive model you should be able to selectively upgrade parts of a system after it is in production. This is where traditional languages like C++ break. There is no class evolution in C++. To evolve a class in C++ you need to recompile/link an entire system. This is one problem component object systems were trying to solve. The iterative approach taken to the limit requires a a dynamic, networked environment and tools and protocols that support software evolvability. And this is where I'd see the link between XML and XP. Application protocols like SOAP or XML-Protocol or whatever it turns out to be promise to create this type of environment. Btw, Martin Fowler categorizes XP as a "lightweight methodology", a category that also includes open source development: http://www.martinfowler.com/articles/newMethodology.html Audio and video presentations and interviews by members of the XP community: http://www.technetcast.com/tnc_catalog.html?item_id=746 Of course a substantial part of the XP movement is about selling books. --PL --- Philippe Lourier Dr. Dobb's TechNetCast http://www.technetcast.com --- At 08:24 AM 12/15/2000 -0600, Bullard, Claude L (Len) wrote: >Pair-based programming is probably better than >the notion that having lots of eyes look at code >improves it and everyone seems to accept that one. >That they should both be on the same machine seems >both awkward and unnecessary. The problem here >is picking the right pair and making sure that >they have and will use complementary skills. The >problems of the "insular coder, the lone hacker, >the hero programmer" etc are well known and have >caused many a business model driven project to >fail. The other extreme of that are the >secrecy obsessed organizations that breed >personal competition into every level of their >employees with carrot and stick management. > >This makes XP almost impossible to implement >in the development groups and leads to the >very common inter department schisms between >the business types (the suits) and the >artistics (the programmers). We are watching >some well-established firms dropped to their >knees in their stock prices as the market >observing a lack of innovation and the failure >to deliver on promises made lose confidence >and simply ignore these companies. This is not >just a dot.com problem; it is epidemic in the >computer science industries particularly where >the CEOs and CTOs have yet to understand that >the Internet business is not about building >a barrier of complexity to competitors; it is >about building simple strong bridges to allies. > >You have to pick a model for interaction that >scales up the levels of the organization. You >can't depend on a power elite; you must depend >on a process that self-validates and self-organizes. >In a sense, these organizations work much the >same way an XSLT stylesheet works; it tries >as much as possible to remove a dependency on >globals and relies on smart recognition of >patterns. That is why the pairing must be >precise; what each one recognizes as they >work together is vital. It isn't a [expletive deleted] >contest; it is a game of styling. > >The problem is control, how to get it, >keep it, and use it wisely to ensure your >company is profitable and employees >are satisfied. Unless you can do this, >the business plans will not be met and >no amount of cajoling or browbeating will >change that downward slide. Our business >depends both on application and innovation >and knowing when to do which of these for >some given project. Whatever else you do, >you must train fear out of the employees >and yourself. Knowledge and a certainty that >what is learned will be applied sensibly leads >to confidence. XP, done well, leads to confidence >in the code and the product, thus the management >must be the styler of confidence, it cannot >be simply, confidential. > >"The problem is not in the stars..." > >Len >http://www.mp3.com/LenBullard > >Ekam sat.h, Vipraah bahudhaa vadanti. >Daamyata. Datta. Dayadhvam.h > > >-----Original Message----- >From: Tim Bray [mailto:tbray@t...] > >Maybe, 20 years after I got into this profession, we can >finally leave behind the notion that the business people >will write a complete spec for what they need, and the >programmers go implement that. It's never worked outside >of a few specialized domains, and never will.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|