kasutatavast arendusmeetodist. Eraldi kirjutisena olevat dokumentatsiooni aitavad märkimisväärses osas asendada näitlikud prototüübid, sobivalt kommenteeritud kood ning kokkulepitud testid. Samas - mõnel puhul on selgitamiseks mugavam lugeda eraldi süstemaatiliselt kirja pandud dokumenti. 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
susele (st teha sihttekst sisuliselt informatiivsemaks, täpsemaks või õigemaks, olenemata lähteteksti vastavast parameetrist). Neid teeb kas kogenud ja enesekindel toimetaja või, mida juhtub vast enamgi, tõlke initsiaator ise. Reaalsuse ebaadekvaatne kirjeldamine võib tekkida sellest, et tõlkija ei ole selle reaalsusega tuttav (näiteks tõepoolest ei ole ise kasutanud seda masinat, mille kasutajajuhendit ta tõlgib), või halvemal juhul tõlkija veendumusest, et lugeja parimal võimalikul viisil informeerimine polegi tema ülesanne, tema lihtsalt tõlgib (st transkodeerib). • Muutused, mille eesmärk on teha tekst keeleliselt paremaks, kuid mis ühtlasi tahtmatult teksti sisuliselt eksitavaks või vähemalt mitmemõtteliseks muudavad. Neid teeb keele- või üldtoimetaja, kes pole isegi aru saanud, millest jutt käib, rääkimata sellest, et
annaabi.ee 
