How You Went Extreme How You Went ExtremeIn this page, we should discuss case histories of people's mindsets moving from no XP awareness thru the first media contacts to some kind of mental or project acceptance. These histories will eventually assist LosTresExtremos? to learn the mechanics needed to surmount the "get it" problem in their literature.
Describe HowYouWentExtreme here.
I admit: I was full for CMM (CapabilityMaturityModel). I thought to be strong was the capability to follow steps (even if these were written by myself). I guess when in the beginning of year 2000, I listened to a presentation on XP, it was weird. Something told me that was what I wanted to do. But in the other hand, two years of brainwashing myself about written procedures and documents, I had to resist to the change else I would have died!
Nights were full of nightmares. But I continued to read on XP... PairProgramming, RefactorMercilessly, RelentlessTesting, DoTheSimplestThingThatCouldPossiblyWork, AlistairCockburn, LaurieWilliams, KentBeck, MartinFowler, WikiWikiWeb, etc. Then XpMailingList... It was like a drug.
I had to talk to colleagues to tell about my discovery without being ashamed by my changes. Questions were asked, answers were given or doubts and more questions were raised. I found a lot of support. Even the team leader began to think about it (I am considering myself as a very bad salesman, but somehow they listened to me! So that is not me, it is what is in XP ;-).
And then I was sent to XpImmersionTwo. And now, we are in the exploration phase for the next project. I am not even afraid of trying these new things. A new me was in me! Sure I have fears, but I am able to confront them. I am now being enthusiast and having more answers that logically make sense.
Being voluntary flexible, we (as a team) are transforming ourselves experimenting XP practices one at time taking the time to discuss these transformations.
I had to do some BigDesignUpFront and started to experience ExtremeHumility. Luckily after suffering only a few years of ExtremeFrustration, I found the ExtremeProgrammingRoadmap. I promptly purchased ChristopherAlexander 's book 'TimelessWayOfBuilding'. A few months latter a book was published about ExtremeProgramming, KentBeck 's 'ExtremeProgrammingExplainedEmbraceChange'. I realized that I have been ReFactoring. I wasn't good at BigDesignUpFront, I was good at ReFactoring, identifying the EmergingPatterns, and making those look like a design. XpImmersionTwo showed me how to apply those principles in a more satisfying way. -- ErikMeade
I returned to news:comp.object after a few months distracted by working a Spiral project (where each "iteration" was really a big WaterFall [less the supporting paperwork]), and discovered the eternal raging debate on that group had centered on something called "eXtreme Programming".
At that time I made a mental image of the process, based entirely on the name. I'd have never done anything with this image and got in trouble for jumping to conclusions, but nothing contradicted the image either.
The image was a bunch of college kids had slapped up a Web page and filled it with "Glory of Programming" bull in between skateboard excursions. I figured the threads occurred because the page got popular among other kids, and the old-timers were threading to talk them down. I disregarded the newsgroup for a few weeks.
Then I observed RobertCecilMartin appeared to take the side of the eXtremos.
I determined from the threads what "RefactorMercilessly" was, and like many I realized that was my guilty little secret. Everyone knows you follow the Cost Of Change Curve from the most stable to the most volatile elements in your code, and you only retrofit or OpenClosedPrinciple things - you never just jump in and screw around. I was shocked (even as late as 1999) to see professionals who value their reputations advocating such irresponsible behavior.
Of course I refactored all the time, and of course my two excuses were "I wrote everything so of course I know what I'm doing", and "I'll leave 'assert(false)' everywhere to force me to track thru this new stuff with the debugger and proof it all."
When I figured out that the first was PairProgramming and the second was UnitTests, that's when it all snapped into place.
-- PhlIp
I was introduced to Extreme Programming in January of 2001 and, although it was not a religious experience, I definitely felt that I was looking at a better way to deliver software. I was working with another developer side by side, with him watching me code and me watching him design. After a few days, he mentioned that this was like something he had heard of called Extreme Programming. A MountainDew commercial immediately sprung to mind! :) However, we were working very efficiently, so I decided to do some research.
We were working on a Java framework that was to be used by the "army of developers" that was to come on a large development project. However, after a couple of months, the client decided to go to a COTS product (which they still haven't actually bought as of June 2002). Sigh.
We never got to the point of using UserStories, and never had any official releases, but we did implement unit tests in a big way. Since we were writing middle tier code as well, I set up the unit tests to be run from a web site in conjunction with our app server. One click ran all of the tests, or any of the tests in the hierarchy.
Anyway, it didn't take me very long to be sold on the XP ideals, and I intend never to look back!
-- DaveRooney
Before reading about XP, I was already a Wiki reader, a Smalltalk programmer, a patterns fan, a fan of KentBeck and WardCunningham, and was trying to improve my own software development process.
In other words, I was already a sycophantic brand-loyal yes-man Cunningham/Kent/Hillside groupie.
So naturally as soon as I read about XP, I adopted it without thinking about it or questioning it.
I'm glad I did adopt it. I especially like unit tests, and the "it doesn't have to be fully correct right now" mentality. -- StanSilver
I think I was born a XpSavage?. undiciplined natural tendency towards XP. Obviously I've never religiously followed it's rules as if set in stone (which doesn't seem to be at the heart of XP at all anyway). I've always worked in a prototyping mode as well as iterative refinement. Start of doing something that does something (anything) and then add the least functionality that makes it do what you want, rinse and repeat.
Where I seriously fail out is the team aspect, as my experience in collaborative programming (even pair) has been limited by the lack of available peers (I've always kept my work off the net).
Is there a possibility for XP-Apprenticeship, where one can join a team, or pair-programming session t osolve a particular task to get into the spirit of things? -- SvenNeumann
Lessons learned using XP.
Lessons learned applying XP to the development of an online banking platform:
The reason it took me so long to start reading about XP, Agile Methods, Refactoring, & Design Patterns is because of bad experiences with Software Engineering books in the past. I had come to the conclusion that SE was not usable for the individual developer. When XP, Agile, Refactoring & Design Pattern books started to appear I just assumed that they were more SE books with techniques that I couldn't easily use. I spent my time learning more about Windows & Linux. What turned me around was finding Extreme Programming Explained by Kent Beck in the library. This book caused me to change the way I develop code as well as completely revamping my reading list. --BillBurris ( from news:comp.object )
Let's concentrate on the goal, not the process. The process is just a vehicle to attain the goal, "good software". Open your minds and look at the substance of what XP says. Don't just dismiss it as "wrong", just because it is counter to the recent direction we have taken in the software development process.
Currently I develop in an environment where we extensively use UML models to build our system. Since the Class Diagrams are the basis for automatic code generation of classes it is fairly easy to make the models "king". Then as the architect, I can control the system design by having an overall view using the Object Models. Over the last year I've gotten very comfortable with this point of view.
Then I stumble against XP while playing with VisualWorks NC SmalltalkLanguage.
My first reaction was, "Are these guys crazy?". But I continued to read, and asked myself, "What if they're on to something?". Some of the points rang so true that it became difficult to dismiss the rest. Once I got the whole picture, it became hard to dispute that they were on to something. The real problem was that I had enough real world experience that validated the arguments XP makes.
Take "PairProgramming". Several of the most productive periods I have had while programming, was while doing this "duet" style where one person "drives" for a while and then the other. This allows both people to be looking at the problem from two points of view at the same time. One, down in the details of syntax and such, while the other can be a bit more distant, able to look at the 20,000 ft. view. This can be critical to good software design, and it helps to pace yourself when you know that if you "run out of gas" for a while, you can turn the wheel over to the other person and you're off and running again.
If XP challenges your view of software engineering, take a step back and see if it is the fact that it shakes up some of your "core beliefs" that puts you off, or if it truly espouses false principles. It seems to me that there are too many examples where the process works to believe the latter.
Remember the goal comes first, not the process. Sometimes the process must change to attain the goal. If XP achieves the goal, then it is a "good" process by definition.
--SteveGilbert?
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006