Vanasti kulus kirikute ehitamisele sajandeid. Aja jooksul arenes aga tehnoloogia ja muutusid inimeste eelistused. Pidevalt muutuvad arhitektid tahtsid väljendada oma isikupära ning seetõttu muutus aja jooksul ka kiriku arhitektuuriline suund. Kahjuks tekitavad sellised muudatused olukorra, kus lõpptulemus ei ole ühegi konkreetse arhitekti nägemus ja puudub ühtne stiil.
Tarkvaras võib kohata sarnast olukorda. Kuna koodi korrashoid (refactor) on väga oluline, siis soovitatakse seda regulaarselt ka teha. Kuid sarnaselt kirikute ehitamisele tuleks mõelda, et kas muudatused oleksid läbivad ja laieneksid kogu arhitektuurile. Kui koodi ümberkirjutamise käigus muudetakse ainult osaliselt arhitektuuri, siis oleks mõistlikum ümberkirjutamisest üldse loobuda. Vastasel korral jääb alles nii vana keerukus, kui ka lisandunud "uus lähenemine".
Hea näide siinkohal on näiteks lähtekoodi jagamine kataloogidesse/paketidesse. Kui alguses tehti seda tüübi järgi, näiteks andmebaasi objektid ühes kataloogis ja teenused teises, siis hiljem ei pruugi olla hea mõte hakata kasutama feature põhist lähenemist.
Teine näide oleks näiteks muuta seda, kuidas moodulid omavahel suhtlevad. Näiteks kasutades alguses mingit keskset järjekorda, siis võttes kasutusele REST ja lõpuks liikudes Kafka peale. Jättes alles, ilma reaalse kasutusloota, ka varasemad suhtluskanalid, muutub tarkvara arhitekuur oluliselt keerulisemaks.
- Mõte pärineb raamatust
- Frederick P. Brooks Jr. (1995) The Mythical Man-Month: Essays on Software Engineering