[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Extreme Programming goes mainstream?
Which sounds good on paper but is a stone cold nasty problem in a contract driven system of testable deliverables over services. The adaptive approach works well at Burger King where all the positions are interchangeable and the components are tested, tasty, and available. Software engineering when coupled to product delivery is not easy to do as a service model. The problem is when the system is complex, highly customized, and costs are recovered in accordance with a delivery/test acceptance schedule. Enabling constant adaptation means you must have very precise contract models for who gets to request and adaptation. Failing to recognize gold-plating, rice bowl requirements, extensions based on lack of up-front analysis, and so on can quickly put you out of business. Its about recognition of patterns and picking the right template. Adaptation is a pattern recognition problem with feedback-based controls. Can you create a root pattern that works just as well for the business model as it does for the engineering problem? The success of SOAP, UDDI, etc. will rise or fall on the means by which discovery and recognition of a service can be followed by negotiation for terms and conditions that satisfy a requirement. Otherwise, you just don't get paid. The recent American election is revelatory of the issues of small noisy systems that contribute to a binary decision which results in a tie. Don't look at the politics; look at the pattern recognition and how lack of robust standard templates makes for a messy outcome. Len Bullard Intergraph Public Safety clbullar@i... http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Philippe Lourier [mailto:pl@t...] Sent: Friday, December 15, 2000 9:47 AM To: xml-dev@l... Subject: 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
|