Rikkinäisiä ikkunoita

Luin hiljan Malcolm Gladwellin kirjan The Tipping Point. Kirjassa tuli vastaan rikkinäisten ikkunoiden käsite.

Kirjassa käsitteellä kuvattiin New Yorkin 1980-luvun rikosaaltoa, tarkemmin ottaen ympäristön vaikutusta sen syntyyn. Kirjan esittelemien tutkimusten mukaan ympäristön hidas rappeutuminen muutti ihmisiä. Kun ympärillä näkyi rikkinäisiä ikkunoita, suuremmatkaan rikokset eivät tuntuneet niin pahoilta.

Yksi ongelmapesäke oli New Yorkin metro. Mitkään toimenpiteet rikosten estämiseksi eivät tuntuneet tuovan tulosta. Tilanne alkoi muuttua vasta, kun uudet johtajat David Gunn ja William Bratton (Metron poliisi) puuttuivat graffiteihin ja liputta matkustamiseen, joihin aikaisemmin ei ollut kiinnitetty huomiota ryöstöjen ja raiskauksien takia. David ja William lähtivät liikkeelle rikkinäisistä ikkunoista vastoin muiden kehotuksia keskittyä suurempiin ongelmiin ja ihmiset alkoivat muuttua.

Rikkinäiset ikkunat toivat mieleeni yksityiskohdat. Kuinka monta kertaa olet ohjelmistoprojektin aikana kuullut, että niihin palataan myöhemmin. Ja kuinka usein niihin on palattu? On ollut isompia ja aina vaan isompia ongelmia ratkottavana.

Yksityiskohdat kuitenkin ratkaisevat usein tuotteen menestyksen. Jos niitä jätetään jälkeen, syntyy Pasin mainitsemaa teknistä velkaa ja huonoja käyttökokemuksia. Kohta sammutetaan tulipaloja, vaikka olisi pitänyt korjata niitä ikkunoita.

Jarkko Järvenpää

Jarkko Järvenpää

5 kommenttia

Kiitos Tuija, olen kanssasi samaa mieltä.

Suoraan tuohon liittyen en muista nähneeni tutkimustuloksia, mutta Gladwellin kirjasta löytyy kyllä useampia esimerkkejä tutkimuksista, jotka käsittelevät ympäristön ja ympäröivien ihmisten vaikutusta henkilön käyttäytymiseen.

Tuija Aalto sanoo:

Uskoisin että sama efekti liittyy ilmapiiriin blogissa tai keskustelufoorumissa. Jos moderaattori osoittaa välittävänsä siitä, missä hengessä keskusteua käydään, keskustelun taho kohenee. Jos jollakulla dataa aiheesta, kiinnostaisi kovasti.

Jarkko Järvenpää sanoo:

Kiitos kommentista Jussi. Kyse on nimenomaan kiinnostuksesta. Jos asioihin ei puututa, se muuttaa kaikkien käyttäytymistä.

Ohjelmistoprojekteissa ei välttämättä ole silti kyse aina siitä, etteikö asia ei kiinnostaisi. Monesti vain “yksityiskohtien” tekemistä siirretään myöhemmäksi.

Ja kun sitten merkataan jotain tehdyksi, vaikka näin ei tosissaan ole, synnytetään valheellinen kuva edistymisestä tai ohjelmiston laadusta. Syntynyttä velkaa maksetaan myöhemmin sitten korkojen kera.

Juha Riippi sanoo:

Tuo rikkinäiset ikkunat -vertaus on suoraan käytössä myös Andrew Huntin ja David Thomasin koodausfilosofian mahtiteoksessa Pragmatic Programmer. Älä siis riko koodissasi sitä ensimmäistäkään ikkunaa, niin on hyvä mahdollisuus että ne kaikki pysyvät ehjinä. Ja jos näet jossain rikkinäisen ikkunan, vaihda se heti ehjään.

Jussi Niskanen sanoo:

Oliskohan ollut Pragmatic Programmerissa ( http://pragprog.com/the-pragmatic-programmer ) tuosta ikkunateoriasta myös. Hylätyn rakennuksen ränsistyminen tapaa alkaa ikkunoista; rakennus voi olla pitkäänkin käyttökelpoinen, mutta kun ensimmäinen ikkuna rikkoutuu ja jää korjaamatta, röpsähtää loppukin nopeasti.

Ilmeisesti kyse ei ole ainoastaa siitä, että muut rikokset tuntuisivat vähemmän pahalta, vaan myös siitä että rikkinäinen ikkuna on merkki, ettei ketään kiinnosta. Ja kaikki kyllä tietävät mitä tapahtuu koodille kun koodaria ei enää kiinnosta. Eli laadun laskiessa kannattaisi paitsi pitää huolta että ongelmakohtiin puututaan ripeästi, pitää myös selvittää miksi laatu laskee.

Liity keskusteluun