Extreme Programming Refactored: The Case Against XP
R
Rapid Development: Taming Wild Software Schedules, 208
reality distortion field. See ethereal wizardry
Recovery via ˜Not XP (VoXP), 252 “253
Refactor (song), 201 “202
Refactorin (song), 211
refactoring, 337 “369
agile, not fragile, 339 “343
contingency vs. embellishment , 342 “343
decreasing risk, 339
encouraging contingency, 339 “340
preventing fragility, 340 “342
C3 project life cycle and, 40 “41
before coding, 308 “309
defined, 12, 202
design documentation and, 178
design documents vs. code, 309
extreme programming in practice and, 27 “28
extreme programming in theory and, 12 “13
frequency of and problems with XP, 62 “63, 66 “68
locations of programmers and, 71
problems reported on the ATLAS Project and, 317
refactorer s responsibility, 67 “68
refactoring iteration, 256
scope creep and, 254 “255
server tools project case study, 362 “368
framework, 366 “367
multiple masters, 367 “368
overview, 362 “363
sufficiency of XP and, 363 “366
size of company and, 305
in small companies, 305
spinning the design and, 304 “305
summary of, 338, 368 “369
taming XP and, 343 “362. See also practices tweaked to tame XP
interaction designer, 359 “362
tweaked to tame XP, 349
refactoring after programming, 201 “226
with installed user bases, 218 “225
corruption of live data and, 221 “222
live user interfaces and, 220 “221
maintenance and, 219 “220
problems with refactoring, 224 “225
refactoring live data, 222 “223
selective refactoring, 225
shielding code from change, 223 “224
simplicity of code, 224
introduction to, 201 “203
refactoring vs. design, 203 “205
summary of, 225 “226
up-front design and, 212 “218
amount required, 216 “218
benefits of, 214 “216
code as design, 212 “213
XP and constant refactoring, 206 “212
shortcomings of refactoring, 209 “212
usefulness of refactoring, 207 “208
Refactoring: Improving the Design of Existing Code (Addison-Wesley, 1999), 69, 207
Refactoring the Database (VoXP), 222 “223
releases
frequency of and problems with XP, 69 “70
problems with early, 299
release planning, 300 “301
small releases ATLAS project problems and, 316
to tame XP, 347 “348
timing of, 297 “300
acceptance tests and, 303
tweaking of XP and, 365
requirements
vs. acceptance tests, 242
agility and, 304
changes to, 307
electronic storage and, 366
goals and, 360
instead of user stories, 365
interaction design and, 310
requirements creep, 294, 303 “304
requirements documentation, 162 “165, 350
requirements elicitation , defined, 357
vs. scope creep, 254
as solution to scalability, 334
summary of issues regarding, 244 “245
timing of maintenance mode and, 310
vs. user stories, 237 “242
about requirements and XP, 237 “239
architecture-shifting requirements, 242
vague requirements, 240 “242
risk and XP, 339
roles in XP, 18 “19
Rosenberg, Doug
amount of up-front design and, 216 “217
on C3 project, 33
ICONIX Process and, 22
on oral documentation, 170 “173
on pair programming, 138
parody on fear, 111 “112
There s No TIME to Write Down Requirements ( satire ), 202
Use Case Driven Object Modeling with UML: A Practical Approach, 22
Royce, Winston, 164