På min arbetsplats argumenterar jag ofta för enkelhet. “Välj det enkla” är en rekommendation som många av mina arbetskompanjoner fått höra. Enkelhet är svårt! Enkelhet har många ansikten! När jag tänker tillbaka och tittar på det jag själv åstadkommit ser jag ibland att min stävan inte har uppfyllts. Det är inte alls enkelt! I denna fundering vill jag ta upp några av de områden där enkelhet kommer in.
Ofta kan man se programvara och affärssystem i synnerhet arbeta efter mottot “ökad funktionalitet” för att stå sig bättre på marknaden. Konkurrenter ska besegras med tillägg av ytterligare en “feature” och programvaran växer. Komplexiteten ökar. Utvecklingen verkar vara en naturlag. Som en frisk fläkt kan man därför läsa 37signals bok Getting Real där “Build less” intar en grundläggande tanke. Slå konkurrenterna med att bygga mindre. Lös de enkla och håll fokus på den viktiga problemen. Var snabbare och billigare. Jag rekommenderar boken varmt.
En annan infallsvinkel mot enkelhet är de implementationer som görs i stora företag. De styrs inte av enkelhet utan mera av betalkraft. De rubriker som Försäkringskassans åstadkom talar sitt tydliga språk. Varför har projekten hos större företag där betalförmågan inte begränsas en tendens att skena iväg. Varför har enkelheten övergivits? Är vi konsulter förblindade av de miljonkontrakt som är möjliga?
Inom utvecklarleden finns också diskussioner som kan kopplas till enkelhet. Rod Johnson kritiserade Javavärdens överarbetade J2EE och tog det som utgångspunkt när han lanserade ramverket Spring. Andra diskussioner är argumenteringen för moduluppbyggnad och “loose coupeling” där strävan är byggstenarnas oberoende allt för att förenkla. På senare tid har devisen “Convention over configuration” blivit vanlig. Allt behöver inte vara konfigurerbart. Det har en nersida i större kodmassa och mer komplicerad kod, installationer blir svårare att sätta upp och inlärningstiden ökar. Framework som tagit sin utgångspunkt i devisen är kända för sin överlägsenhet beträffande den tid som behövs i utvecklingsarbetet.
Det finns ytterligare en sak som jag vill peka på. Det är den svåra men så viktiga kommunikationen mellan användare och utvecklare. Brister resulterar i att utvecklare har en diffus uppfattning om vad som ska lösas. Denna osäkerhet avspeglas också i lösningen. Den bli onödigt komplicerad. Man har tappat enkelheten.
Har IT-hantverkarnas ständiga följeslagare i form av problemlösarinstinkt satt sina djupa spår. Det enkla problematiseras och blir svårt. Finns det en bristsjukdom i vår bransch. Brist på enkelhet.