Dette er en artikkel i kategorien refleksjon og det kommer som et resultat av det jeg har erfart i de siste årene hvor Smidig-bevegelsen virkelig har blitt allemannseie. Jeg har både vært team medlem, Scrum Master, arkitekt og delvis produkt eier i ulike sammenhenger. En ting har alltid ligget å ulmet i bakhodet mitt de siste årene og det har med begrepet enkelhet eller simplicity. Begrepet brukes til veldig mye rart og har blitt en viktig ingrediens i alle dokumenter om visjoner og strategier. Alt skal være enkelt. En annen setting hvor enkelhet nevnes hyppig er i diskusjoner rundt konkrete løsninger. Her brukes begrepet ofte som hersketeknikk hvor den som kommer med “men det er jo ikke enkelt” eller “det er unødig komplisert” forsøker å parkere andre forslag. Det er i denne andre konteksten hvor det hele tiden har skurret i hodet mitt. Veldig ofte bruker man begrepet enkelt på en måte som tilsier at noe skal være banalt eller simpelt. Løsninger som involverer teknikker eller noen biblioteker blir ofte merket som kompliserte (ofte med unødvendig som prefix).

Enkelhetens lover

Enkelhet kan oppnås på mange måter, hvor en av de er å redusere og fjerne noe. Dette er grunntanken de fleste forbinder med enkelhet, men etter å ha lest John Maeda sin The Laws Of Simplicity ble jeg klar over at dette er bare en av veldig mange teknikker som kan brukes til å oppnå enkelhet. Maeda oppsummerer enkelhet i ti lover som kan brukes i et arbeid med å oppnå enkelhet i løsninger. I det daglige hører jeg stortsett snakk om å oppnå enkelhet gjennom Lov 1: Reduser. Det er selvsagt en viktig teknikk for å oppnå enkelhet, men den er overvurdert særlig i forbindelse med å løse problemer som oppstår under systemutvikling. Dersom det er en problemstilling som ikke er triviell, så er det faktisk slik at det er en del andre lover som faktisk gir bedre resultat enn bare å redusere kompleksitet og å “dumb it down”. Organisering og kunnskap fører veldig ofte til enkelhet i løsningen, på tilsvarende måte som loven om å redusere.

Simplifisering mer enn bare å redusere

Hvis du må lage et rammeverk for å utøve f.eks mapping fra ett objekt til et annet, så kan det gjøres enkelt dersom du sørger for at rammeverket er godt organisert og hvis du sørger for å la de som skal bruke det få økt kunnskap gjennom eksempler og dokumentasjon.  Veldig mange vil si at å lage et rammeverk strider imot det å gjøre noe enkelt, men det blir for enkelt mener jeg. Et godt skrevet rammeverk som er testet og skrevet brukervennlig vil jeg si er essensen i enkelhet. Du gjør en ofte utført operasjon enkel for flere. Hvorvidt det ligger avansert kode i rammeverket er egentlig uinteressant. Ingen stiller spørsmål rundt hvorvidt Spring rammeverket bruker noe avansert for å oppnå det de gjør. Hvorfor skal man i prosjekter måtte gå kanossagang om man ønsker å benytte seg av noe som av enkelte oppfattes som avansert?

Balanse

Enkelhet består ikke i å fokusere på reduksjon eller bare å se på tidsbesparelser. Evnen til å vurdere flere av lovene slik at de balanserer hverandre ut som er nøkkelen til å oppnå enkelhet. Det viktigste er likevel å innse at for å oppnå enkelhet kreves mer enn reduksjon. Hvis du synes utvikling av web applikasjoner er vanskelig med Java verdens mange rammeverk, så blir det ikke bedre av å redusere alle slike å bare bruke servlet klassene. En slik drastisk reduksjon er ofte fundert på en tanke om enkelhet, trukket altfor langt. Ofte bunner slike på manglende kunnskap eller behov for å bevise noe, som begge er krefter som trekker i retning av “dumbing down”: ikke enkelhet.