Přepis aplikace má tu výhodu, že máte k dispozici údaje, které nebyly původně k dispozici. Nevýhodu máte v tom, že musíte znova realizovat zadání zpravidla za několik let, což je obvykle víc práce, než se v evangelizačním nadšení zprvu zdá. A stále tam zůstává problém skrých předpokladů - use-casů, které se sice používají, ale zákazník si to vůbec neuvědomuje.
Typické reakce jsou: Ta nová verze je hrozná, nejde tam udělat XY a zrovna tohle v původní verzi fungovalo skvěle. Cože, vy jste něvěděl, že to takto používáme?? No ale za to mi nemůžeme, přece jsme nechtěli, abyste nějakou funkčnost rušil, mysleli jsme že to bude fungovat jako dřív a že si to jen nějak uvnitř uzpůsobíte aby se v tom vám lépe programovalo a aby to bylo rychlejší...
K principu DRY: Někdy je lepší se opakovat a zachovat ortogonalitu, než se za každou cenu neopakovat a vytvořit přebujelou hiearchii tříd nebo do sebe zaklesnutých pomocných modulů, které rádoby dělají tu věc, které se nemá opakovat, ale jsou špatně navržené. Takže než vytvořit nezvládnutou abstrakci, je lepší to psát jednoduše. V tom dost pomůže prototypování - otestuje se, zda zvolená architektura zachycuje reálné potřeby.
Kvalitu si představuje programátor typicky jako elegantní návrh (a možná i jako odolnost vůči chybám), uživatel požaduje hlavně srozumitelné gui no a manager to chce zítra :-)