Tämä juttu käsittelee minulle läheistä aihetta, ylisuunnittelua (over-engineering). Koen kulkeneeni jo pitkän matkan niistä ajoista, kun liiketoiminnalliset vaatimukset tuntuivat lähinnä ärsyttävältä kiusalta haittaamassa hienon järjestelmän rakentamista. Siihen aikaan koodasin esimerkiksi omia C++-kirjastoja, koska en luottanut standardikirjastoihin. Nykyään oma ajattelu on paljon lähempänä tavoitteiden saavuttamista ja järjestelmien rakentelu on vain keino siihen.
Jutussa esitellyt käsitteet ovat luultavasti tuttuja kaikille koodaajille. Yritämme luonnostaan aina rakentaa yhtä isoa, täydellistä, geneeristä järjestelmää, jota on "sitten myöhemmin" helppo laajentaa kattamaan uudetkin tarpeet. Mutta kuten jutussa todetaan, nämä uudet tarpeet onnistuvat joka kerta yllättämään niin, että hieno suunnitelma menee uusiksi ja vanhat järjestelmät lentävät romukoppaan. Samalla suuri osa työstä on ollut turhaa ja ylimääräistä vaivannäköä, kun on pitänyt työskennellä oman abstraktion eikä varsinaisen ongelman parissa.
Näistä syistä itselläni särähtää aina korvaan, kun joku perustelee arkkitehtoonisia päätöksiä pelkästään periaatteellisilla näkemyksillä. Yritän olla sortumatta tähän ja käytän mieluummin perusteena käytännön kokemuksia tai käytännöllisiä arvioita siitä, mitä tulee tapahtumaan juuri tässä tapauksessa.
Aika paljonhan nimittäin pystyy peilaamaan asioita sen kautta, miten omat projektit ovat käytännössä sujuneet ja mihin niissä on käytetty ylimääräistä aikaa. Se on tärkeämpää kuin suurten auktoriteettien julistamat periaatteet, jotka ehkä osuvat yksiin omien projektien kanssa tai sitten eivät.
Kaikesta tästä käytännöllisyydestä huolimatta en toisaalta mittaa arvoa pelkästään rahassa tai työtunneissa. Arvostan enemmän luovaa työtä kuin toistuvaa rutiinityötä, joka on mielestäni syytä automatisoida. Siksi olen valmis panostamaan hieman enemmän vaivannäköä saadakseni aikaan ratkaisun, joka toimii "ikuisesti" ilman ylläpitoa. Tästäkin joutuu kyllä toisinaan tinkimään oikeissa projekteissa, joissa halutaan yhä pitää ylläpitäjät mukana kuvioissa. Mutta sen analysointi jääköön myöhemmäksi.
https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8#.8js0qac10