I apologize for the length of the following, but the answer is so contrary
to conventional wisdom that a short answer is worse than none at all.
A reasonable set of questions.
1. Better than previous process? I generally get hired because things are
in the toilet for a project. After I get hired, things often (but not
always) get better. I attribute the difference to what I do, or I couldn't
justify charging for my services.
This isn't a comparison with what Doug does. I've never cleaned up a mess
of his, nor he a mess of mine. So the claim isn't very strong if you want
to compare his process with his presence and my process with my presence.
2. Code easy to change? This was only true for a few special projects 20
years ago (the LISP community comes to mind). There are a list of practices
and technologies that make it possible today, although it is easy to get
back out on the steep slope.
The only way to believe this is to experience it. Get the free version of
VisualWorks and the Refactoring Browser. Build your favorite simple little
program. Then start slamming the design around in the code.
Once I got good at this, I was able to apply the same style of development
to Java. It's easiest in VisualAge Java, but I've done it in Cafe also.
Someone else will have to speak to the possibility of doing it in C++.
Databases certainly complicate the picture. I find Gemstone an excellent
tool for continuing to evolve a design even with production data. Again,
you have to have the tests, you have to go in small steps, you have to have
a partner, and you have to practice.
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). The question is,
what negative feedback do you use?
I observed that people didn't enjoy, and didn't actually use the feedback
mechanisms that they read about- synchronized documentation, big testing
processes administered by a separate group, extensive and fixed
requirements. So I decided to look for feedback mechanisms that
1) people enjoyed, so they would be likely to adopt them,
2) had short-term and long-term benefits, so people would tend to stick
to them even under pressure,
3) would be executable by programmers with ordinary skills, so my
potential audience was as large as possible and,
4) had good synergistic effects, so we can pay the cost of the fewest
Enough philosophy, here are the feedback loops, how they slow the process,
their short and long term value, and their most important synergies:
Planning Game- You have to wait until you have the stories before you begin
production coding. The short term value is that the programmers are
relieved of the burden of making decisions that they are unprepared to
make. Longer term, the programmers only implement stuff the customers are
sure they need, and the customers can change the direction of development
on a dime. The Planning Game enables most of the other practices by
reducing the bulk of what needs to be considered by the programmers at any
one time to their customer's immediate needs.
Functional testing- You can't continue development until the functional
test scores are acceptable to the customer. The short term value is that
the programmers know when they are done with the functionality, and the
customers are confident that the system works. Longer term, the functional
tests prevent regressions and communicate important historical information
from a customer perspective. The functional tests back up the unit tests to
ensure quality and improve the unit testing process.
Unit testing- You can't release until the unit tests are 100%. The short
term value is that you program faster over hour and greater time scales,
the code is higher quality, and there is much less stress. Over the longer
term, the unit tests catch integration errors and regressions, and they
communicate the intent of the design independent of implementation details.
The unit tests enable refactoring, they drive the simple design, they make
collective code ownership safe, and act as a conversation piece enhance
Refactoring- You can't just leave duplicate or uncommunicative code around.
The short term value is that you program faster, and you feel better
because your understanding and the system as seldom far out of sync. The
long term value is that reusable components emerge from this process,
further speeding development. Refactoring makes good the bet of Simple
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. In the
long run, simple design ensures that there is less to communicate, less to
test, less to refactor.
Metaphor- The system is built around one or a small set of cooperating
metaphors, from which class, method, variables, and basic responsibilities
are derived. You can't just go off inventing names on your own. The short
term benefit is that everyone is confident that they understand the first
things to be done. The long term benefit is that there is a force that
tends to unify the design, and to make the system easier for new team
members to understand. The metaphor keeps the team confident in Simple
Design, because how the design should be extended next is usually clear.
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. Collective Code Ownership makes refactoring work
better by exposing the team to more opportunities for big refactorings.
Coding Standards- You can write code any way you want, just not on the
team. Everybody chooses class names and variable names in the same style.
They format code in exactly the same way. There isn't a short term benefit
to coding standards that I can think of. Longer term, coding standards that
are chosen for communication help new people learn the system, and as the
standards become habit, they improve productivity. Pair programming works
much more smoothly with coding standards, as do collective code ownership
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.
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
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.
Those are all the practices I regularly teach. Contexts with less stress
will require fewer of the loops to maintain control. I just talked to a
five year old project I coached as I was formulating the beginnings of XP.
They work for a great company, on a project with rapidly changing but not
urgently changing requirements, with 3 engineers. They get by just fine
with metaphor, unit tests, 40 hour weeks, coding standards, and
There are certainly contexts that will require more practices- ISO
certification, FDA auditing requirements, complicated concurrency problems
requiring careful review, complicated logic that no one can figure out how
to segment. However, the above works for my customers.
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. 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.
Mark, if you've made it this far, have I answered your question about how
XP could possibly work?
Again, I apologize for the length of the foregoing. If someone has a good
idea for shortening it (aside from deleting entirely), I would love to hear
Do NOT sent signoff request to firstname.lastname@example.org, please!!!
To unsubscribe from this list, please send email
Body: unsubscribe otug your_full_subscription_address
This archive was generated by hypermail 2b29 : Thu Jul 13 2000 - 22:37:57 EDT