Väiksema tarkvara esmase loomise ajal on enamik teabest mugavalt kättesaadav tegijate peades ning selge sihtmärgi puhul edeneb töö ka ilma eraldi nõudeid, struktuuri ja kasutajajuhendit kirja panemata. Ka väiksema rakenduse puhul kipub loomise käigus unustamisi ette tulema, kuid nendest saab enamasti üle ka esmaste katsetuste või kaaslasepoolse meeldetuletuse abil. Kui aga tegijaid on rohkem, nad ei suhtle pidevalt vahetult või rakenduse loomine/muutmine jääb pikema ajavahemiku sisse, siis mälu põhjal töötav arendus enam ei toimi. Uuesti rakenduse juurde pöördudes kulub märkimisväärne osa ajast olemasoleva meelde tuletamise peale ning mõnedki algselt kokku lepitud põhimõtted ja piirangud võivad kergesti tähelepanuta jääda kui neid eraldi kirja pandud ei ole. Koodi sobiva struktuuri ja lühikeste asjalike kommentaaride abiga võib rakenduse ülesehituse meelde tuletamine (vahel isegi kümnetes) kordades lihtsustuda.

Võrdluseks - Java või .NETi standardteekides olevate tuhandete klasside ja kümnete tuhandete käskude seas on pärast mõningast tutvumist võimalik paketipuud kaudu sobiva kohani jõuda üldjuhul maksimaalselt paari minutiga, enamasti sekunditega. Või siis sama teed kaudu veenduda sobiva käsu puudumises. Kui aga on tegemist mitmetest osadest suhteliselt suvaliselt ühendatud sobivalt dokumenteerimata veebisüsteemiga, siis võib üksiku pealtnäha lihtsa vea leidmiseks ja kõrvaldamiseks kuluda päevi. Ehkki klasse on vaid paarkümmend ning kasutatavaid käsklusi kokku mitte üle paarisaja (teksti autori isiklik kogemus). Veel hullem, kui kood pole üldse mõistlikul kujul klassideks ega meetoditeks jaotatud. Sel juhul võib juba paari tuhande realine rakendus tunduda selline müsteerium, et lihtsam on sama tulemuse saavutamiseks rakendus uuesti kirjutada kui olemasolevat parandama hakata.

Uuesti kirjutamine ei pruugi sugugi alati paha mõte olla ning seda ei tasu ka liialt karta. Peab ainult tundma ja kindel olema, et uuel kujul rakendus märgatavalt paremini hallatav ja edasi arendatav on. Küllalt sageli võib selline ümber tegemine otstarbekaks osutuda juhul, kui rakendus eelmise versiooniga võrreldes on kolm või rohkem korda suuremaks paisunud. Mõned arendajad püüavad sellist ümbertegemisvajadust vältida ning kohe algul luua põhjaliku struktuuriga arendusprojekti, kus igal osal ja koodilõigul on kindel koht. Sellisel juhul aga kipub tulemuseks olema ka näiteks lihtsa kalkulaatori puhul mitmeteistkümne kataloogi ning mitmekümne failiga projektipuu, kus rakendusespetsiifilist sisu on siiski vaid paari faili seest. Selline lähenemine võib mugav olla tarkvarafirmade puhul, kus suurte rakenduste struktuur on selgelt välja kujunenud ning meeskond oskab sobilikke lõike kergesti leida. Kui aga tegemist rakendusega, mille tegevusloogika saab kirjeldada paari ekraanitäie programmikoodiga, siis on lühikesel lahendusel oma võlu - eriti, kui selle koodiga peavad hiljem tegelema mitmesuguse taustaga programmeerijad eri arendusvahendite abil. Isegi siis on kompaktne kood vahel mugav, kui on teada, et paari aasta pärast tuleb see süsteemi kasvamise ning nõuete muutumise tõttu märgatavalt ümber teha.