The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Originally posted by Tad Takahashi:
I am doing a research about social impact in/of software development for one of the graduate college courses I am taking.
We have to ask people for their real work experience.
I chose eXtreme Programming as my topic.
I thought that it would be a good idea to start a new discussion
here about it.
The followings are the questions I would like to ask.
Any feedback will be greatly appreciated.
1. What were the benefits (in social context) you found when you implemented Extreme Programming?
(Did it change your relationships with your colleague or manager? Did it change the group dynamics of your team? How did that social aspect in return affect the quality of the software you developed?)
We used pair programming in some of our classes which were teaching introduction to OOP programming (Java) here at the Dept of Informatics, University of Oslo, Norway. I can't speak for XP as a whole since this was only done on a small population and only one time, so statistically I'd be careful about concluding to much.
The problem initially was that the fail percentage was fairly high after we switched from Simula (OO language since 1967to Java. To remedy that several methods where looked at with the aim to make them better programmers at the end of the semester.
The result was that when the two programmers were at the same level and the chemistry was good, these people felt support by having one extra pair of eyes and also made code with better readability and less errors.
2. What were the disadvantages (in social context) you found when you implemented Extreme Programming?
(Did it change your relationships with your colleague or manager? Did it change the group dynamics of your team? How did that social aspect in return affect the quality of the software you developed?)
Ofcourse, in a introductory course when you most likely don't know anyone prior to attending the course there was ofcourse a few where maybe the ambitions differed or that the chemistry and differences was too big to overcome.
The result could be that one person did most of the coding while the other were inactive and did not manage to understand what all the code did.
3. Extreme Programming has some controversial pieces (e.g. Pair Programming). When you or your organization started using Extreme Programming, how was the reaction of your colleague, your manager, or the whole of your team?
I'd ve sceptical about working in a pair for all my programming, but it is certainly a good thing to discuss and share code. Its often that I have some code with an impossible to find bug, but upon showing it and explaining it to a friend which knows some about the inner workings and ask some questions I usually discover the code much quicker than if I were to fiddle around by myself.
4. Related to Question 3, how did you, your colleague, your manager, or the whole of your team deal with the reaction?
5. If you have anything else your found related to social aspect of implementing Extreme Programming, please describe it here.
Like it was said in another thread. eXtreme Programming is all in whole fairly extreme, but it does have some really good points which could be introduced without to much trouble. The more extreme parts could be introduced gradually on a long term and adapted to what does work in your company/situation.
Thank you
Originally posted by Tad Takahashi:
1. What were the benefits (in social context) you found when you implemented Extreme Programming?
(Did it change your relationships with your colleague or manager? Did it change the group dynamics of your team? How did that social aspect in return affect the quality of the software you developed?)
3. Extreme Programming has some controversial pieces (e.g. Pair Programming). When you or your organization started using Extreme Programming, how was the reaction of your colleague, your manager, or the whole of your team?
author of:<br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201485672/electricporkchop" target="_blank" rel="nofollow">Refactoring : Improving the Design of Existing Code</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/020165783X/electricporkchop" target="_blank" rel="nofollow">UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201895420/electricporkchop" target="_blank" rel="nofollow">Analysis Patterns : Reusable Object Models</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201710919/electricporkchop" target="_blank" rel="nofollow">Planning Extreme Programming</a>
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Originally posted by John Wetherbie:
I guess I see the Coach's role as more of a mentor than a director.
John[/B]
author of:<br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201485672/electricporkchop" target="_blank" rel="nofollow">Refactoring : Improving the Design of Existing Code</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/020165783X/electricporkchop" target="_blank" rel="nofollow">UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201895420/electricporkchop" target="_blank" rel="nofollow">Analysis Patterns : Reusable Object Models</a><br /><a href="http://www.amazon.com/exec/obidos/ASIN/0201710919/electricporkchop" target="_blank" rel="nofollow">Planning Extreme Programming</a>
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Originally posted by Tad Takahashi:
I chose eXtreme Programming as my topic.
I thought that it would be a good idea to start a new discussion
here about it.
Originally posted by Matt Stephens:
You may be interested in a feature currently going on at the Bad Managers website.
Although most people seem to accept XP, Bad Managers are taking an opposing viewpoint. Makes a refreshing change!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
It could be refreshing if they were not so ill-informed.
XP is aimed at clueless customers who don't know what they want
being guided by mediocre programmers who have even less idea what the customer wants.
in their eyes it is okay to be confused
"Don't worry, we'll just start running as hard as we can in a random direction, and if it turns out to be the wrong way, we'll just turn around. It won't cost you any extra, because turning around is free."
Coding in pairs could never be as effective as one competent developer daring to think for themselves.
XP attempts to flout the physical laws of the Universe, by making it "okay" to make changes at any stage in the project.
This isn't just accepting change as a necessary evil, but positively encouraging change (even after a significant amount of code has been written)
flying in the face of reality, convincing otherwise intelligent people who should know better, that change is somehow free.
XP empowers programmers to make business decisions.
Have XP, have spaghetti code with lots of IF statements.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
[B]I can't find the latest XP article anymore. I will just start at http://www.bad-managers.com/rumours/xp/extreme-programming.shtml
For the purposes of this article, I have concentrated on the extremeprogramming.org website (i.e. on their particular "flavour" of XP). I am sure some will argue that this isn't the "real" XP.
XP does state that you don't have to practise all of it: just the parts that suit your project. From the extremeprogramming.org website:
"Usually projects come looking for... XP only after the project is in trouble. In this case... figure out what is slowing you down. Add XP to this problem first..."
<br /> From <A HREF="http://www.extremeprogramming.org/when.html:" TARGET=_blank>http://www.extremeprogramming.org/when.html:</A> <br /> >>>XP is set up for small groups of programmers. Between 2 and 10. [...] But you can not use XP on a project with a huge staff.<<<<br /> This doesn't say that huge begins by eleven programmers. In fact the definition of 'huge' would mostly depend on your experience and your definition of the boundaries of XP.<br />XP appears to be aimed at small projects. It doesn't scale. [...] How many programmers do you need? XP says 2-10 (any more and XP won't work).
<br /> There simply is no 'one size fits all' methodology - you will always have to adapt your process if the project size changes.<br /> On the other hand: >>>We should note that on projects with dynamic requirements or high risk you may find that a small team of XP programmers will be more effective than a large team anyway.<<< [http://www.extremeprogramming.org/when.html]<br />This [the non-scaling] is a tad presumptious, given that they (and I, and everybody else) can have no idea what size your project is going to be.
<br /> From <A HREF="http://www.extremeprogramming.org/rules/userstories.html:" TARGET=_blank>http://www.extremeprogramming.org/rules/userstories.html:</A> <br /> >>>About 80 user stories plus or minus 20 is a perfect number to create a release plan during release planning.<<<How many "user stories" should your project consist of? Eighty. <br /> What I assume they're really saying is that you should start with about eighty, and take it from there.
Of course, the release plan will still result in the customer initially being quoted eighty, because nobody has thought any further ahead than that yet. ...
The basic fact is that if you don't know in advance exactly what you want from your new system, then the project can't be costed. It can't have a budget (not a meaningful one, anyway). Its resources can't be accurately forecast, hence nothing can reasonably be allocated (except maybe for the upcoming two weeks).
The following two rules* are true of any project. Each of these is an absolute. No "silver bullet" methodology (least of all XP) can change this reality:
The most important decisions are made at the start of any human endeavor.
This is when we address questions such as "What to do?", identify goals and select strategic plans of action.
The cost of change increases as any project progresses. Later on [...] the interactions of thousands of decisions have increased the complexity of making change.
Constant refactoring [...] is dangerous [...] (not to mention encouraging programmers to optimise unnecessarily)
Unit tests may introduce more bugs than they prevent because you've now got twice as much code
and a change to the mythical requirements means many changes to all that source code
and testing the tests to make sure they still reflect the requirements, that is if anyone had them written down somewhere
Is the customer really going to spare a senior decision-maker for an entire year?
and we're back at the start of the loop.
From extremeprogramming.org: "The release plan used to be called the commitment schedule ... A useable, testable system that makes good business sense delivered early is desired"
Now let's see: Useable... yes; testable... yes; makes good sense, yeess... delivered early? Hang on a second. I have had the unfortunate privilege of knowing a good few managers who would take this implicit promise as a sign to over-promise to the customer: "Our team say this defence project will take them 16 months to complete. But wait just a second, they're using this project to try out XP! That means I can just go ahead and promise the customer half that time instead. Way to go guys!"
Software isn't an amorphous gooey substance that can be shaped, moulded and re-shaped as you go along.
Whatever the XP-ites tell you, there's a cost penalty involved.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
OK, so let's examine http://www.bad-managers.com/Features/soapbox/xp.shtml:
There is also a cost involved in not being able to reshape the system to new needs. There is a cost involved in not being able to hold complexity to minimum as the system evolves. There is a big cost involved in trying to analyze the whole big system in detail up front.
XP assumes that with modern tools and techniques, the cost of reshaping the system pays back manyfold.
Originally posted by Matt Stephens:
As Kent Beck asserts in XP Explained, pretty much all of XP's benefits rest on his claim that XP can flatten the cost-of-change curve. It's this claim that I find the most dubious.
Originally posted by Matt Stephens:
Ill-informed? Which part? This seems to be a common reaction from XPites - dismiss the article with a wave of the hand, without explaining why.
I'm fully prepared to update the article based on constructive criticism - the article says as much.
Nothing up my sleeve ... and ... presto! A tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|