Extreme Programming Experiences: Part 5 of 5 – Pair Programming is for 100% of production code, not 100% of your workday

Pair Programming is for 100% of production code, not 100% of your workday

Pair Programming is intense, mentally and physically. You need to take breaks, stretch, walk around, and hopefully go outside for sunshine and fresh air. Even so, 8 hours of solid pair programming is a very tiring day. That much pairing time may be appropriate now and then, but it isn’t physically sustainable.
Continue reading “Extreme Programming Experiences: Part 5 of 5 – Pair Programming is for 100% of production code, not 100% of your workday”

Extreme Programming Experiences: Part 4 of 5: Technical Debt and Cruft

Technical Debt and Cruft

There is a fundamental tension in software development between delivering something quickly now, and being able to deliver something quickly later. Over time, quick and dirty hacks pile up, and code becomes difficult to work with.
Continue reading “Extreme Programming Experiences: Part 4 of 5: Technical Debt and Cruft”

Extreme Programming Experiences: Part 3 of 5: Lack of Onsite Customer

Lack of Onsite Customer

This is a serious problem. Your project exists to serve somebody, and your success is directly proportional to understanding what they want, so that you can build it. You need as much communication bandwidth between the programmers and those people as possible.
Continue reading “Extreme Programming Experiences: Part 3 of 5: Lack of Onsite Customer”

Extreme Programming Experiences: Part 2 of 5: “Lazy YAGNI”

“Lazy YAGNI”

You Aren’t Gonna Need It can lead to some silly situations if you interpret it too pessimistically. The pessimistic (and wrong) interpretation is that you should pretend that the user story you’re implementing is the only one you know about. This equates to doing zero up-front design, because you’re only concerned with whether the design satisfies the user story you’re currently implementing. The price of making this mistake is design churn: each new requirement may incur a large rewrite of existing code. This is obviously not a recipe for productivity.
Continue reading “Extreme Programming Experiences: Part 2 of 5: “Lazy YAGNI””

Extreme Programming Experiences: Part 1 of 5: Do The Simplest Thing That Could Possibly Work

Do The Simplest Thing That Could Possibly Work

This does not mean “do the least work possible”. Doing the least possible is not XP, it is hackery, which is the methodology that leads to a Big Ball of Mud.
Continue reading “Extreme Programming Experiences: Part 1 of 5: Do The Simplest Thing That Could Possibly Work”