Mainitaan alkuun mielestäni tärkein periaate, että mitään periaatetta ei tule seurata sokeasti tai dogmaattisesti. Kaikki riippuu aina tilanteesta, ja hyväksi havaitut käytännöt voivat joissain tapauksissa olla pahasti haitaksi. Siksi kannattaa olla tietoinen keskenään ristiriitaisista periaatteista ja hankkia monia tapoja toimia ja ajatella. Itselleen kannattaa rakentaa useita malleja, jotka auttavat päätöksenteossa ja vähentävät henkistä uudelleen keksimisen taakkaa.
Teknologiset periaatteet
Sellaiset, jotka ilmenevät pääosin tekstieditorissa
KISS
Eli keep it simple, stupid. Älä rakenna toteutuksistasi liian monimutkaisia.
YAGNI
YAGNI eli you aren’t gonna need it. Älä yritä huomioida joka ikistä tulevaisuuden potentiaalista mahdollisuutta tai edge casea. Et muuten saa ikinä mitään loppuun, ja auttamatta teet asioista monimutkaisempia kuin on tarve. Tähän liittyy myös yksi pahimmista synneistä nimittäin ennenaikainen optimointi, mikä syö resursseja, aikaa sekä fokusta siitä, mitä pitää saada nyt ja seuraavaksi aikaiseksi.
Loogiset tasot
Pidä eri loogiset tasot toisista irrallaan. Layerien sekoittaminen yhdeksi mössöksi johtaa niin sanottuun ”spagettikoodiin”, jossa asioiden keskinäiset riippuvuudet ovat arvaamattomia ja vaikeaselkoisia. Muutosten tekeminen on tällöin hankalaa ja riskialtista. Esimerkiksi domain-tyyppien pitäminen irrallaan visuaalisesta kerroksesta auttaa järjestelmän muutostöitä tulevaisuudessa, sillä renderointilogiikka ja sisäinen bisneslogiikka kehittyvät eri tavoilla ajan saatossa.
Dokumentaatio
Dokumentaatio itsessään auttaa muita ihmisiä, mukaan lukien tulevaisuuden itseäsi. Välillisesti dokumentaatio kertoo projektin sekä tiimin ryhdistä ja voinnista yleensä. Dokumentaatioon liittyy myös versiohallinnan historiatieto. Commit-viestien järkeellisyys, mielellään atomiset commitit, ja ylipäätään versiohallinnan sekä julkaisuhallinnan suunnitelmallisuus ja johdonmukaisuus – kaikki tämä reflektoi tiimin pieteettiä ja sitä kuinka ammattimaisesti ohjelmistokehitykseen suhtaudutaan, ”pelkän koodaamisen” sijaan.
Riittävän hyvä
Laadun ja ajan välillä ilmenee väistämättä ristiriitoja. Laadullisesti hyvä koodaussuoritus on eri asia kuin laadullisesti hyvä ohjelmistokehityksen suoritus, sillä jälkimmäiseen on sidottu aika, budjetti ja kommunikaatiota. Täydellisen eleganttia, suorituskykyistä ja kaikkia hyviä käytäntöjä huomioon ottavaa algoritmia ei yleensä kannata hieroa. Riittävän hyvä “gets the job done” -suoritus riittää monesti yllättävän pitkälle, ja optimoimaan päästään myöhemmin. On toki tilanteita, jotka pitää saada kerralla oikein – joko aikaan sidottuja asioita tai toimialasta riippuvia rakettikirurgisia suorituksia tekeviä tai tukevia ohjelmistoja.
Teknologiavalinnat
Nice to have, bleeging edge tai miten ikinä ilmaistu uusin hotti tekki ei yleensä ole se mitä oikeasti tarvitaan. Joskus tylsä teknologia on parempi valinta. Tylsä teknologia ei välttämättä stimuloi koodaajan älyllisiä nystyröitä tai tyydytä pahinta uuden oppimisen kiimaa. Tai houkuttele nyt tai tulevaisuudessa niitä osaavimpia tekijöitä hankkeen pariin. Valintoja tehdessä täytyy joka tapauksessa tehdä jonkunasteinen arvaus sen kestävyydestä ja houkuttelevuudesta tulevaisuudessa, eikä tähän ole ennalta määrättyjä oikeita vastauksia. Aiempi blogautukseni teknologiavalinnoista sivuaa samaa aihetta.
Käytäntöjen periaatteet
Sellaiset, jotka ilmenevät ihmisten välisessä yhteistyössä, vuorovaikutuksessa ja erilaisissa projektinhallintajärjestelmissä
Ihmisten kanssa toimiminen on usein vaikeampaa kuin tekstieditorin kanssa. Avoimen lähdekoodin kanssa toimiva ohjelmistokehittäjä näkee miten kaikki toimii, kaikessa loogisuudessaan tai epäloogisuudessaan. Toinen ihminen, minä itse, ja ryhmädynamiikat sen sijaan ovat vähintään semi-mustia laatikoita.
Yhdessä sovitut käytännöt
Ensimmäinen hyvä käytäntö on käytännöistä sopiminen. Ne sovitaan ryhmän kesken ja jokaista jäsentä kunnioittaen. Minkään tiimin käytäntöjä ei kannata puristaa tiettyyn muottiin, vaan kunkin jäsenen tarpeet tulisi sovittaa hankkeen tarpeisiin.
Suunnittelu ja arviointi
Kaikki tekeminen alkaa, tai tulisi alkaa, suunnittelusta ja arvioinnista. Kuinka paljon aikaa tämän tekeminen ottaa meidän tiimiltä? Aikatauluja arvioidessa ihminen on hyvin usein optimistinen ja aikataulut monesti venyvät. Toisaalta, pessimistinen arvio saattaa Parkinsonin lain puitteissa toteuttaa itseään, eli arvioitu jäljellä oleva aika täyttyy kuin automaattisesti jostain yksityiskohtien hieromisesta tai turhasta parantelusta. Arvioita tehdessä kannattaa elää rinnakkaisia todellisuuksia, nimittäin antaa sekä optimistinen arvio että realistinen arvio, ja mahdollisesti laskea vielä pessimistinen arvio jollain kertoimella. Näin meillä on sitoutuminen optimistiseen arvioon tai “stretch goal” -kaltaiseen tavoitteeseen, mutta toisaalta sidosryhmillä pelivaraa lopullisen aikataulun kanssa.
Vastuunjako
Kaikessa ketteryydessä ja itseohjautuvuudessa vastuut kannattaa sopia mahdollisimman selkeästi. Vastuu ei aina tarkoita asian tekijää, eikä vastuu ole välttämättä lukittu nimeen tai titteliin. Esimerkiksi joku voi olla vastuussa siitä että asia hoituu, ja häntä kokeneempi henkilö voi olla se kuka asian lopulta hoitaa. Tärkeintä on, että tiedämme kuka tai ketkä hoitavat ja mitä.
Arkkitehtuuri vastaa tiimien rakenteita
Vertikaalinen tiimi, jossa vastuu mahdollisimman monesta asiasta jakautuu samalle ryhmälle, välttää tiedon siiloutumista ja vain oman tiimin tarpeisiin rakentuvaa arkkitehtuuria. Vastaavasti tunnetaan nimellä Conwayn laki.
Soveltaminen ja metataso
Voiko periaatteita soveltaa ohjelmistokehityksen ulkopuolella? Entä voiko ohjelmistokehityksessä soveltaa muita ei-perinteisiä prinsiippejä? Voi toki.
KISS ja YAGNI pätevät ohjelmistokehittämisen lisäksi esimerkiksi kirjoittamiseen, viestimiseen tai organisaation rakenteiden tai prosessien kehittämiseen. Ajankäytön suunnittelu ja varatun ajan täyttyminen “jollain” pätee yleisesti kaikkeen projekti- tai taskipohjaiseen työhön.
Yksi kestosuosikeistani on ns. Lindy-efekti, eli mitä kauemmin jokin asia on ollut olemassa, sitä kauemmin se todennäköisesti tulee olemaan olemassa. Esimerkiksi PHP, jQuery, Cobol, yms. ovat saavuttaneet niin laajan käytön, että niiden kaikenkattava korvaaminen jollain toisella asialla on erittäin hidasta ja kallista.
Näkökulmien laajentaminen
Kun käyttää itselle tuttuja periaatteita, voi yksinkertaistaa liikaa asioita ja nähdä vain oman erikoisosaamisensa näkökulman. Asiantuntija jossain ei ole automaattisesti asiantuntija toisaalla, mutta saattaa kuvitella olevansa. Tutustu esim. ylivertaisuusvinomaan eli Dunning-Kruger-vaikutukseen ja
Hankkimalla ymmärrystä ja yleissivistystä eri toimialojen asioista sekä toimintamalleista voi luoda uusia tapoja käyttää eri periaatteita yhdessä. Tämä vaatii aivoilta myös enemmän työtä; pitää olla kyvykäs ja halukas toimimaan epävarmuudessa ja harmaalla aluella, kun asioita ei aina voi sovittaa oman erikoisosaamisensa lokeroihin.
Monien kulmien tarkastelu ja periaatteiden sovittelu vie aikaa ja energiaa. Lopputulos on kuitenkin parempi kuin mustavalkoinen ajattelu.
