Kent Beck <email@example.com> wrote:
#3. Here we get to the heart of the difference. First, I think we all agree
#that software development process require negative feedback loops to keep
#the system from going out of control (someone who understands system theory
#please tell me if I am saying something patently stupid).
I disagree. And a person is not necessarily stupid for not seeing something.
Often feedback should be "positive" to correct a "negative" trend. In other
words, feedback doesn't always have to be negative to damp a trend, feedback
may be required to be positive to promote or reinforce a trend.
#Simple Design (or Precisely Enough Design)- The right design for the system
#at any moment is the design that 1) runs all the tests, 2) says everything
#worth saying once, 3) says everything only once, 4) within these
#constraints contains the fewest possible classes and methods. You can't
#leave the code until it is in this state. That is, you take away everything
#you can until you can't take away anything more without violating one of
#the first three constraints.
#In the short term, simple design helps by
#making sure that the programmers grapples the most pressing problem.
I don't see how adherence to the above 4 points means the program necessarily
has to be dealing with "the most pressing problem".
The good thing is that if "runs all tests" by the "Simple Design" means the
system runs all tests which confirm fulfillment of at least all key project
use cases, then the "Simple Design" is the right design.
#Collective Code Ownership- If you run across some code that could be
#improved, you have to stop and improve it, no matter what. The short term
#benefit is that your code is cleaner. The long term benefit is that the
#whole system gets better all the time, and everyone tends to be familiar
#with most of the system.
If the code is for instance of tertiary (3rd'ary) importance, I don't see why
it must necessarily be improved immediately when some flaw in it is
#Continuous Integration- Code additions and changes are integrated with the
#baseline after a few hours, a day at most. You can't just leap from task to
#task. When a task is done, you wait your turn integrating, then you load
#your changes on top of the current baseline (resolving any conflicts), and
#running the tests. If you have broken any tests, you must fix them before
#releasing. If you can't fix them, you discard your code and start over. In
#the short term, when the code base is small, the system stays in very tight
#synch. In the long term, you never encounter integration problems, because
#you have dealt with them daily, even hourly, over the life of the project.
#Continuous integration makes collective code ownership and refactoring
#possible without overwhelming numbers of conflicting changes, and the end
#of an integration makes a natural point to switch partners.
The idea of regular integration is good. But we do part and subsystem
integration on a weekly basis for this project estimated to take 2 to 3 years.
the project has internal iteration cycles of 2 months and external iteration
cycles of 4 months.
#On-site Customer- You can't just take your understanding of requirements
#and design and implement with them for a month. Instead, you are in hourly
#contact with a customer who can resolve ambiguities, set priorities, set
#scope, and provide test scenarios. In the short term, you learn much more
#about the system by being in such close contact. In the longer term, the
#customer can steer the team, subtly and radically, with much more
#confidence and understanding because such a close working relationship is
#built. The Planning Game requires an on-site customer to complete
#requirements as they are about to be built, and functional testing works
#much better if the author of the tests is available for frequent
Of course, you stay in touch with the client in this manner.
#Three to go-
#Open Workspace- The best XP workspace is a large bull-pen with small
#individual cubbies around the walls, and tables with fast machines in the
#center, set up for pair programming. No one can go off and hack for hours
#in this environment. That solo flow that I got addicted to simply isn't
#possible. However, in the short term it is much easier to get help if you
#need help just by calling across the room. In the long term the team
#benefits from the intense communication. The open workspace helps pair
#programming work, and the communication aids all the practices.
#Forty Hour Week- Go home at 5. Have a nice weekend. Once or twice a year,
#you can work overtime for a week, but the need for a second week of
#overtime in a row is a clear signal that something else is wrong with the
#project. Over the very short term, this will definitely feel slower. But
#over a few weeks, and certainly over the course of months, the team's
#productivity will be higher and the risk will be lower. Over the long term,
#XP's reliance on oral history demands a certain level of stability in the
#staff, and 40 hour weeks go a long way towards keeping people happy and
#balanced. Rested programmers are more likely to find valuable refactorings,
#to think of that one more test that breaks the system, to be able to handle
#the intense inter-personal interaction on the team.
#Pair Programming- This is the master feedback loop that ensures that all
#the other feedback loops stay in place. Any myopic manager can tell you
#with certainty that pair programming must be slower. Over the course of
#days and weeks, however, the effects of pairing dramatically reduce the
#overall project risk. And it is just plain fun to have someone to talk to.
#The pairs shift around a lot (two, three, four times a day), so any
#important information is soon known by everyone on the team.
Not sure about this. I'd like to try it. But ehhhh.... it don't sound right.
#Looking at the list, it is still hard to imagine how XP can fly, not
#because it so out of control, but because it is so completely controlled.
C'mon. Now I've given you pretty straight hearing above, but XP practice of
coding right from the start, and documenting via the programmers and code is
not "completely controlled".
#I think the reason it works is because none of the practices require a PhD to
#execute, and they are all fun, or at least stress relieving, and they all
#contribute, directly and obviously, to the system.
To me not doing as much or overall investigation before the bulk and heart of
high level production code is not either fun or stress relieving--quite the
-- :=***=: Objective * Holistic * Overall pre-code Modelling :=***=: Hallmarks of the best SW Engineering study Craftite vs. Full Blown OO: http://www.access.digex.net/~ell copyright 1999 Elliott. exclusive of others' writing. may be copied freely only in comp., phil., sci. usenet & bitnet & otug. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Do NOT sent signoff request to firstname.lastname@example.org, please!!! To unsubscribe from this list, please send email To: Subject: <BLANK> Body: unsubscribe otug your_full_subscription_address
This archive was generated by hypermail 2b29 : Thu Jul 13 2000 - 22:37:58 EDT