Die andere Seite der Kontroverse, die XP so populär machte, waren falsche Hoffnungen. Das Umfeld der Software-Entwickler in diesen Jahren war geprägt durch

- Software-Entwicklungsprozess-Optimierungen,
- riesige oft unnötig zu schier unkontrollierbarer Größe aufgeblasene Projekte
- Komplexitäten hochmoderner Mehrschichtarchitekturen.

Die Probleme der für den aktuellen Anwendungsfall meist weitgehend unsinnig komplexen drei- und mehrschichtigen Architekturen waren meist selbstverschulde. Dennoch fühlte man sich in der Gilde der Software-Entwickler schuldlos gefangen in diesem Dilemma, hoffte auf den, die Kreativität endlich wieder zur Geltung bringenden Befreiungsschlag durch eXtreme Programming.

Die Softwareentwickler allerdings, die von ihrem Management bekamen, was ihr Begehr war, mithin XP einführen und benutzen durften, mussten schnell feststellen dass XP nicht der Beginn der Befreiung ihrer künstlerischen Natur war und ist. Stattdessen fordert XP. Es fordert das, was der Künstler im Softwareentwickler am wenigsten zu geben bereit ist.

XP fordert "Einfachkeit über alles"

XP fordert vor allem aber Einfachkeit über jede künstlerisch wertvolle, zukunftsweisende, aber für das aktuelle Projekt völlig überzogene, hochkomplexe Architektur.

XP fordert Orientierung auf den aktuellen Businessnutzen (ROl) des Kunden statt auf das modernste technisch Machbare.

Kurz XP fordert Pragmatismus orientiert an

- Disziplin
- schnelle Realisierung
- businessorientierte Entwicklung und
- stabil lauffähigen Lösungen orientierten.

All das kann Software‑Entwicklern Spaß machen. Es fordert aber ggf. mehr Disziplin und Teamfähigkeit, als all die stringenten strukturierten und/oder iterativen Prozessmodelle, deren Einführung man so verfluchte, von denen man sich durch XP zu befreien gedachte.