Impatient Programming:
A gentle introduction.

Coming soon. The whole method goes up shortly. Got the password? Come on in.

Extreme Programming made a lot of sense by taking things that were considered "best practice" at the time and turning them up as far as they could go. For example, if testing is good, then test all the time. If integration is good, integrate continuously.

XP took off like a wildfire in the year 2000 because it answered two failures at once. Both failures are back with a vengeance. The new BDUF is machine-generated plans that nobody reads. The new wild west of no-software-process-development is nothing other than vibe coding.

XP can inspire what comes next. Take what works, turn the dials up to 11, and give the result a catchy brand name people can rally around. I'm calling it Impatient Programming. IMP for short. Practitioners are Imps, and we keep our clankers on tight leashes.

In IMP the metaphor/mental model gets written down in the source code. We call it the Contract. XP's own values carry over untouched: communication, simplicity, feedback, courage and respect. IMP was born at ZAR.

The Rules Planning Managing Designing Coding Testing twenty-nine of them, 1999 next to 2026

In 1999 Don Wells put the rules of Extreme Programming on a single web page, in five groups. I went through all twenty-nine and asked the same question of each one. What does it look like when typing is nearly free and you have a team of agents at your side?


The Article | Impatient Programming Rules | The Contract | About the Author

With a nod to Don Wells and extremeprogramming.org, 1999.
Last modified October 2, 2026.